Karlperkins12345
Programmer
Is it possible to completely control the construction of Forms by using an Ini file
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Creating Forms Via INI files
- Thread starter Karlperkins12345
- Start date
- Status
Sort of. VB6 has a limitation in that if you want to dynamically create controls, a sample of that type of control must already exist on the form. So you'd have a button, a combo-box, a listbox, etc. all already on the form, but with their visible property turned off, and their Index property set to 0. Your code would then read the form definition info from the INI file, and then calling the Load function to create another instance of the control (see "Adding to a Control Array at Run Time" in VB help).
Chip H.
Chip H.
I'm not sure what the point of doing this is. If you open up an .frm file in Notepad, all that you'll find is a text description of what the form should look like and the code in it. This being the case why would you want to have to type everything out in a text file when you can use the more user-friendly IDE supplied with VB. I suppose it would save you buying licenses but with the extra trouble it would take to write the ini files and the extra bulk needed to reference everything you might possibly need, you have to ask yourself is it really worth it? That said you probably do have a good reason to do which I'd love to hear because despite what I've already said it sounds like a pretty interesting thing to do ;-) Durkin
- Thread starter
- #4
Karlperkins12345
Programmer
The reason I want to use it because Im writing a Report server and I want to be able to create forms that ask for parameters on the fly so that the technical support guys where i Work or customer can customise reports rather than having to recompile every time. I would use the Ini like a scripting language
MichaelRed
Programmer
Not sure I want to understand you (could be a LOT of work). I have provided a minimal dynamic report generator in VB, but based it on a db (Ms. A.) table. It required a fairly LARGE ammount of work, but the basic table structure is not all that difficult (rembering that the report generator was minimal. If I rember it, the table structure include the "section" (header, detail or footer), the field to display, the format, location of the field, font attributes of the field. The Header and Footer section were limited in some respects, like the number of "Lines" of plain text available, while the Detail section was limited to the total "width" for the sum of the field width (Plus the starting (Left most) position.
Given that the info was in a table, It was only really necessary to read the table and 'follow directions'. Some parts are somewhat vague in memory (the organic one), but it was more of a hassle than I wanted to deal w/, basically because "USERS" would often 'design' the prototypical GiGo evoloution -and THEN complain about how BAD the system was ...
MichaelRed
m.red@att.net
There is never time to do it right but there is always time to do it over
Given that the info was in a table, It was only really necessary to read the table and 'follow directions'. Some parts are somewhat vague in memory (the organic one), but it was more of a hassle than I wanted to deal w/, basically because "USERS" would often 'design' the prototypical GiGo evoloution -and THEN complain about how BAD the system was ...
MichaelRed
m.red@att.net
There is never time to do it right but there is always time to do it over
Michael -
I've done something like that too, and the biggest hassle was figuring out which textbox, checkbox, etc. the user had touched. Sure you got the index number in the clicked_event(), but you had to map that somehow to a database field or field in a structure of some kind. Which meant storing some meta-data in a collection. Messy!
Chip H.
I've done something like that too, and the biggest hassle was figuring out which textbox, checkbox, etc. the user had touched. Sure you got the index number in the clicked_event(), but you had to map that somehow to a database field or field in a structure of some kind. Which meant storing some meta-data in a collection. Messy!
Chip H.
MichaelRed
Programmer
chiph,
for RELATIONAL dbs (something reasonably close to the ANSI standard), I set up a lookup process. It is a-la the "Drill Down" method - just using the "system" tables to generally ferret out the sources and characteristics. Again, mine was pretty simplistic -and VERY prone to USER DISsatisfaction (not to mention plain errors).
Basically, my position is that if the USER knows enough to reasonably develop their own reports, they should be given READ access to the tables and set up their own reporting systen (seperate db). Form that vantage, they may develop useful reports which MAY be incorporated into the production app for general use. I have -in other threads- discussed an approach which permits USERS to post objects for consideration of incorporation into the production app. This process provides a great deal of independence for the knowledgeable user, while maintaining security of the production app. For users who are NOT at the level of independent development of objects within the db, I prefer to have their input in the form of a "suggestion" box - which may be incorporated directly into the db, or maintained in any suitable / acceptable manner.
MichaelRed
m.red@att.net
There is never time to do it right but there is always time to do it over
for RELATIONAL dbs (something reasonably close to the ANSI standard), I set up a lookup process. It is a-la the "Drill Down" method - just using the "system" tables to generally ferret out the sources and characteristics. Again, mine was pretty simplistic -and VERY prone to USER DISsatisfaction (not to mention plain errors).
Basically, my position is that if the USER knows enough to reasonably develop their own reports, they should be given READ access to the tables and set up their own reporting systen (seperate db). Form that vantage, they may develop useful reports which MAY be incorporated into the production app for general use. I have -in other threads- discussed an approach which permits USERS to post objects for consideration of incorporation into the production app. This process provides a great deal of independence for the knowledgeable user, while maintaining security of the production app. For users who are NOT at the level of independent development of objects within the db, I prefer to have their input in the form of a "suggestion" box - which may be incorporated directly into the db, or maintained in any suitable / acceptable manner.
MichaelRed
m.red@att.net
There is never time to do it right but there is always time to do it over
- Status
