...or even the Count property of the Forms collection...
________________________________________________________________
If you want to get the best response to a question, please check out FAQ222-2244 first
'If we're supposed to work in Hex, why have we only got A fingers?'
Sorry I assumed that you would loop through the Forms collection (rather than the loaded collection), but you could just use a For Each loop couldn't you!
________________________________________________________________
If you want to get the best response to a question, please check out FAQ222-2244 first
'If we're supposed to work in Hex, why have we only got A fingers?'
You can open the project file for the app adn simply check / search for the lines with "Form=" as the first 5 charactere. The remainder of the line is the form.
Note that you must either use a text editor (e.g. "Notepad") or open the file programatically (as text). Simply clicking on the file will instantiate VB with the project.
Something else to be aware of is that the project file itself only specifies where the forms can be found (ie. the full path) - but it doesn't tell you what they are called.
For that, you must open the corresponding frm file, and you'll find a line like "BEGIN FORM xxx", where xxx is the name of the form in code.
The original question said << at runtime >> which would suggest that the .vbp may not be available.
________________________________________________________________
If you want to get the best response to a question, please check out FAQ222-2244 first
'If we're supposed to work in Hex, why have we only got A fingers?'
Sorry, I was reading and responding to mmilan and MichaelRed where they were referring to the project file and assumed they were talking about .vbp. I guess I had better pay more attention to the origional topic from now on.
In my experience, it has always been 'available'. It may be somewhat hazzardous to make changes to it, but simply reading should not be a problem. I have often used it (the Project file) as a resource for various 'gllobal' changes to VB projects, such as adding a 'trace' routine to EVERY procesure, generating documentation routines and even (occassionally) doing large scale updates/conversions from an older version (of VB) to a current/newer version.
In the latter case, I always (for safety and convenience) generate NEW versions of the objects in a seperate (NEW) directory (folder) and copy the project file - making sure all of the references are 'local'.
In my experience, it has always been 'available'. not on the clients machine at runtime. In which case you would have to have already saved the names to some list because forms that are not loaded will not be in the forms collection. With the forms listed you can then access the unloaded forms with strongm's FormByName function found here thread222-25016.
"Two strings walk into a bar. The first string says to the bartender: 'Bartender, I'll have a beer. u.5n$x5t?*&4ru!2[sACC~ErJ'. The second string says: 'Pardon my friend, he isn't NULL terminated'."
interesting. very interesting. of course, strongm is correct. foolish me 'expecting' the discussion to be re "development". Curious as to what use a PC "operator" might make of the information. Seems like they would either have to be able to "access" any forms via the menu structure provided or get into the IDE to make ANY use of objects (or listingss thereof) listiings (forms, modules, ... ). Perhaps someone would educate me?
It seems to me that no wrong answer has been given. The only real problem is assumption. We are not given enough information to provide a necessarily definitive answer. I would suggest that the origional poster (ejgb) clarify what they want to acomplish and at what level. I submit that before we make an even bigger mountain out of this mole hill that the following questions be answered. (1) Is this for your (the developer's) use only? Knowing this we can provide you with the best solution for your specific need and we all we be on the same page. (2) Do you really want just a list of all the forms in a project or just the ones that are loaded at a specific point? johnwm makes a very valid point provided the info is needed at run-time (developed, compiled and distributed) but then MichaelRed makes another valid point ...if we assume run-time (developement/developer stage) and that there would be no usefull purpose for the end user (non developer) to have access to such a list.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.