Check whether a form is opened as subform

[NauticalGent]

If .ControlType = acSubform

I didn't know that was part of the ControlType enums. Learn something new every day...

 

[Pat Hartman]

nd I will continue to do that

That prevents you from using properly named report objects.

really don't like the way you are forced to populate the custom combobox list. You populate a table first, then each individual record needs to be added one at a time to the combobox list and then you delete the record just added to the list and start all over again with the next record.

Not sure what you're talking about but my combo's RowSources are always populated using queries and never with code.

Keeping a table as I (and others) described earlier solves the "sub" problem since you only ever want to see main forms/reports. The table also gives you the opportunity to use good object names as well as friendly user names which just using MSysObjects doesn't support. I don't ever run into the other problem because I don't allow two forms to ever be open at the same time unless one is in dialog mode so it has to be closed for control to return to the other form. If you do allow multiple active forms (sure hope your users are on the ball), then I suppose you could use a table where each form adds its name when it opens and deletes it as it closes. That lets you avoid all the confusing code and just use queries to control the menu lists. Also, in Northwind some (but not all) forms allow multiple instances of the same form to be open. That actually makes more sense than allowing multiple different forms to be open. The only use case where I could envision a user having to have multiple forms open is if one is being used for reference and that worries me that there might be a design flaw.

 

[GPGeorge]

That prevents you from using properly named report objects.

Not sure what you're talking about but my combo's RowSources are always populated using queries and never with code.

Keeping a table as I (and others) described earlier solves the "sub" problem since you only ever want to see main forms/reports. The table also gives you the opportunity to use good object names as well as friendly user names which just using MSysObjects doesn't support. I don't ever run into the other problem because I don't allow two forms to ever be open at the same time unless one is in dialog mode so it has to be closed for control to return to the other form. If you do allow multiple active forms (sure hope your users are on the ball), then I suppose you could use a table where each form adds its name when it opens and deletes it as it closes. That lets you avoid all the confusing code and just use queries to control the menu lists. Also, in Northwind some (but not all) forms allow multiple instances of the same form to be open. That actually makes more sense than allowing multiple different forms to be open. The only use case where I could envision a user having to have multiple forms open is if one is being used for reference and that worries me that there might be a design flaw.

As Pat noted, Northwind Developers Edition supports multiple open Orders forms and multiple open Invoices forms. That allows a user to compare items in two or more different orders without having to close and reopen the form for the second (or subsequent) order. The same applies to invoices.

The code which supports multiple copies of these forms is provided for you in Northwind Developers Edition.

Featured Access templates - Microsoft Support

Analyze and store large amounts of information, and manage data more efficiently with Access database templates available for download.

support.microsoft.com

 

[Pat Hartman]

Actually, rather then using a table where the rows are constantly added and deleted, maybe this is a use for a collection or dictionary. Not sure if that solves the bloat problem but it might.

 

[The_Doc_Man]

Actually, rather then using a table where the rows are constantly added and deleted, maybe this is a use for a collection or dictionary. Not sure if that solves the bloat problem but it might.

Pat, I'm going to offer an OPINION that if the dictionary content is treated as volatile (i.e. insert, update, and deletion of dictionary name/values happens a lot), it will contribute to the bloat problem and will be fixed by the Compact & Repair action that copies (and compresses as it works) EVERY OBJECT in the DB file to a new DB file.

The problem with garbage collection isn't WHAT is being collected but HOW it is being collected. Which is why the problem would be there. But in Access or any other Office tool that allows you to create memory-resident scratchpad items, you will have the same problem, though there may differences in degree - but not in kind.

The only method I've ever seen to improve traditional "scratchpad" garbage collection was in the OpenVMS operating system, using what they called a "lookaside list." Basically, rather than allocating the exact amount of space you need for a structure, you have a bunch of pre-allocated, fixed-size structures in a formal double-ended queue. If you need a chunk of scratchpad memory (up to the size of the pre-allocated chunks), you just allocate the whole chunk regardless of how much less you actually need. When done with the allocated chunk, you release it via a routine that re-threads it back into the double-ended queue (a.k.a. dequeue, pronounced "deck"). I don't know if Windows does this, but Microsoft and Digital Equipment DID have a teaming agreement for a while and shared technology. (Where do you think MS learned how to build cluster machines?)