Subform hatred: after a few hours of fooling with one

[psemianonymous]

1. When you close the main form, any changes made to the subform will either be saved or lost. There is no option to 'cancel' the form close. Compare this to making changes on the main form -- if you 'cancel' the BeforeUpdate event when someone is trying to close the form, a special dialog pops up that says 'you're about to lose everything, close anyway?' With subforms, this doesn't exist. BAD.

2. Subform timing issues. I thought that the the subforms loaded, then the main form. It turns out, this isn't true. The main form loads, then, sometime later, the subform loads. So if you're trying to mess with the subform's information based off of the main form's Me.OpenArgs property, you have to do something messy to get it to work. Ick.

3. Are you supposed to put all the code in the main form's module, or the subform's module? Either way, it's all terrible. Me.ctlSubformA.Form![txtSomeControl], blah. Or, the 'cleaner' way: Me.ctlSubformA.MessWithRecord arg1, arg2. Blah. See #2 for an example of how this sucks (sprinkle timing issues and it's double the pleasure). Blah.

4. I know why pressing TAB cycles INSIDE the subform, but I don't have to like it. This is a bad feature. There should be an option for subforms that say 'jump to next control on main form, instead of looping through records.' Yes, this is a real gripe. Pain.

5. Leaving the subform's focus to the main form triggers the Before_Update() event (i.e. tries to save the record BEFORE MOVING). Unnecessary, but it does so. Again, I know this is a 'feature', not a bug, but it's a terribly annoying feature.

6. The mild indentation non-lineup. Subforms are about half a click off of the grid.

7. Vertical scrollbars, or the space taken up when they aren't visible, have an unchangeable background color that does not change with the subform's background (probably an Access 97-only bug).

8. Inability to use comboboxes in the datasheet mode, except by using a feature Which Will Remain Unnamed, For It Is Horrific. Thus I use continuous form and try to make it look like a datasheet, a fate nearly as awful as using That Which Is Unnamed.

9. Did I mention you can't tab OUT of a subform? Terrible, especially when I'm trying to 'hide' the fact that I'm using subforms in the first place.


If I think up more items, I'll post back.

 

[jrbarnett]

Foolio12

Re No. 1, if you use the Form_Unload event, this is called just before the Form_Close, and can be cancelled.

John

 

[MichaelRed]

... I generally just don't use subforms, except to display data. While there are (or may be) advantages, I find the limitations outweigh whatever those may be. I do, however, often use subforms to display data entry processing. I generate the "continuious form" version of the data entry form for the details section of a composite (e.g. Po form with the header and detail tables combined, but the details as the subform). I then copy the subform countrrols to the Parent form (and (- yes - alas - alack and awry) do some crude alignemnt over the subform controls. Next, remove the ControlSource from the Main field controls, add a few command buttons, some validation code (and possibly lookups to the main for data enbtry form). While some what the long way around, it provides a great deal of control overhbte data entry process, particularly in the V&V area, with out getting involved in the intricacies of the beffor / after update & cancel operations. It is all done "right in front" of me, and I can provide explicit and immediate feedback to the user 'in situ'.


Probably a "poor' approach, but I have found it to be useful and effective and a work-around for the pesky problem of trying to base a form on a query w/ the one to many relationship as well as the subform issues.




MichaelRed
m.red@att.net

Searching for employment in all the wrong places

 

[TheAceMan1]

[blue]Subform timing issues. I thought that the the subforms loaded, then the main form. It turns out, this isn't true[/blue]

Have to correct ya here. you had it right the first time. [blue]SubForms load first![/blue]

This can be easily tested by including an [blue]Debug.Print[/blue] in an commonly used event such as [purple]OnOpen[/purple] or [purple]OnCurrent[/purple] (After the forms open, do not close them. Minimize the main window, open a module, then the immediate window). Do this and you'll see the subs load first. I've done this in the past using all the events that trigger when forms are open and under all possible conditions.

This is also a good technique to use when having problems with focus events. Its very revealing. I've gotton out of quite a few nightmares this way.

See Ya! . . . . . .

 

[CajunCenturion]

On the loading issue, you're both right and wrong because of what you mean by "load." You must understand that a SubForm is, to the main form a CONTROL, just like a textbox, or combobox. The Form must load first, because none of its controls can be loaded until the form is loaded. Now when the SubForm control is loaded, it them goes into its initialization routine which the form load event.


Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[CajunCenturion]

Talk about early Enter. Need more coffee!!!

Anyway, as I was trying to say before I interrupted myself, the subform initialization is completed before the main form initialization, and its start up event fire before the main form events fire.

The actual order of events is as follows:

SubForm Open - SubForm Load - SubForm Current - MainForm Open - MainForm Load - MainForm Activate - MainForm Current

Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[2drunk2funk]

Glad I am not the only one who thinks subforms are awfully implemented.
I will only use to do some static displays.

Anything that needs an ounce of control or complexity rules out a subform for me.
I end up coding my own "form in a form" setup.
Should not have to do it though.

 

[CajunCenturion]

I like using the MSHFlexGrid. I got cell level control (ie no conditional formatting) on formatting (fonts/colors etc), sort on any column, Insert in the middle, at the top, at the bottom, sort at runtime on any column,
almost complete control over the display.

The two downsides are that requirements of copying and registering a new DLL to install, and the lack of intrinsic editing, which has been solved by hidden controls.

The only time that I've found a subform to be useful, is that I can include several fields from an entirely different DataSource and keep all fields updateable, when combining the two queries results in non-updateable recordset.

Good Luck
--------------
To get the most from your Tek-Tips experience, please read FAQ181-2886
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein