jwcolby
jwcolby at colbyconsulting.com
Wed Aug 8 09:26:56 CDT 2012
This sounds like way more than I would want to get into based on the dynamic sizing. However I would NOT use a common class simply because a class is supposed to model an object, the code required for that object and the variables needed for that object. You have three objects, the main form and two subforms and from the sounds of it each is very different. Thus putting all this stuff in a common class breaks all the rules of object oriented programming for little or no gain. I would have three classes. Once you do that, the main form's class can have hard coded pointers to the two subform's classes (if you will only ever have two) since those subforms "belong to" the main form. BTW if the child classes are dimensioned WithEvents in the parent class, then the child can raise events and those events can be sunk up in the parent class which makes a lot of things very easy to handle. Suddenly the parent can "see" the OnCurrent of the child (for example) simply by raising a "evCurrent" down in the child class in the child's OnCurrent event sink. You can even do an "evBeforeCurrent" and an "evAfterCurrent" if you need the granularity. Likewise the subforms could be passed a pointer to the main form's class and stored as a "PointerToParent" property. Now the child form classes can call methods of their parent to communicate as needed, even custom methods for each child form if desired. Or, as mentioned above, if the child dimensions the PointerToParent WithEvents, then it can sink events raised by the parent class. Think about using communications such as this between your parent and child classes. As you have probably discovered long ago, if you use bound forms, child form's load their data before the parent and their events start firing before the parent which I have found to be a nasty issue to deal with. My solution has been to unbind the child subforms at design time. When the parent opens, its data loads and its events fire and it then dynamically binds the child forms when the parent form wrapper class is ready for the child forms to start processing. As I have mentioned many times, I have an entire framework which I use for my projects. I have a dclsFrm which is a wrapper for a form, dclsTxt, dclsCbo etc. Each class wrapper has built-in functionality for these objects and can raise events etc. I have been doing this kind of stuff for about 10 years now and can offer general "wisdom" (?) about class / withevent kinds of issues. The resizing stuff is something that I have never dealt with directly. I used the Getz stuff from long ago (the late 90s) but never really liked the results and (at that time) it was way over my head and so I never tried to troubleshoot the issues I had with it. John W. Colby Colby Consulting Reality is what refuses to go away when you do not believe in it On 8/8/2012 9:34 AM, A.D. Tejpal wrote: > Suggestions are invited for any additional enhancements that could be considered for incorporation in proposed sample db for simulated split form. The arrangement envisages two adjacent subforms, one below the other, separated by a divider bar. Top subform serves as single form while the bottom one represents datasheet portion. > > Certain features that could be considered desirable for inclusion, are listed below: > > 1 - Ease of adaptation: > The developer should need to simply assign the given single form as source object for the top subform. Based upon generic template, datasheet portion of split form should get generated automatically in the bottom subform, displaying columns matching bound controls in single form above. > > 2 - Consolidation of code in a common class: > Necessary code for integrated coordination between main form as well as its two subforms should be consolidated in a common class, instantiated in open event of main form. Nominal code for raising custom events can be added to single form's module. > > 3 - No added burden for data loading: > Datasheet subform can use the recordset already loaded for single form, thus avoiding any additional burden. > > 4 - Divider bar: > (a) Divider bar can be dragged for dynamic expansion / shrinkage of datasheet and single form heights at run time. > (b) On opening the split form, divider bar should assume the position last held in previous session. > > 5 - Re-size nominated controls on single form: > For added convenience, certain controls on single form, e.g. text box bound to memo field or even an image box, can be slated for vertical re-sizing so as to best utilize the available space resulting from divider bar movement. > > 6 - Hiding / Un-hiding of datasheet columns: > On opening, datasheet columns matching memo fields can be in hidden state. The user can hide any other column by double clicking the same. Similarly, any column can be un-hidden by double clicking the matching control on single form. > > 7 - Auto adjustment of datasheet column widths: > (a) At any given stage, the width of displayed columns should get adjusted automatically, so as to ensure optimum utilization of available width of datasheet window, duly taking into account the latest status of hidden / un-hidden columns. > (b) For a given single form, on opening for the very first time, datasheet columns can be of equal width, suiting available space. Thereafter, if the user has manually adjusted the column widths, any further automated adjustment of column widths in response to hiding / un-hiding of columns should be carried out in such a manner as to retain relative proportion of column widths. > (c) On click of a command button, the user should have the option to reset all column widths as if it were the first opening of form. > > 8 - Highlights: > (a) When a datasheet column is in hidden state, corresponding control in single form gets highlighted in light grey. As and when the column is un-hidden, matching control on single form reverts to its normal color. > (b) Current row in datasheet gets highlighted in light green. > (c) As the user tabs from one control to the other on single form, matching cell on current row of datasheet gets highlighted in distinct color (say light maroon). > > 9 - Search Action - Positioning of destination row in datasheet window: > Based upon search action performed via suitable controls (like combo box) on the single form, the destination row on datasheet should get positioned at middle of display window. This should take into account dynamic datasheet window height resulting from movement of divider bar. > > Best wishes, > A.D. Tejpal > ------------ >