I have an application in which the windows are supposed to behave like Microsoft Word. I open the application and it displays me the Menu. From the menu, I select an option and another window opens up (not in the same screen space). basically I would be calling another Exe that is supposed to open this window. How do I accomplish this.
"I have an application in which the windows are supposed to behave like Microsoft Word. I open the application and it displays me the Menu. From the menu, I select an option and another window opens up (not in the same screen space). basically I would be calling another Exe that is supposed to open this window. How do I accomplish this."
MS Word is an MDI type container so that any child forms MUST appear in the same frame (you use the word "Space" do you mean "Frame" or do you want the subsequent forms to appear in a different region of the Window?). Therefore, when you close the Parent form, all child forms also close. If that is what you want, then all your forms will share the same menu and tool bars. However, any controls you have on the first form will show through all the child forms.
If you want your subsequent forms to appear outside of the opening form window, then you do not use the MDI structure. If you want to show the subsequent forms only after you have opened the first form, then instantiate those forms in the first form. This will still mean that when you close the first form all the other forms will be closed.
Taxes
The more I learn about VB.NET the more I like dBaseIII Plus
The foregoing, whilst believed to be correct, is given without guarantee as to it's accuracy and entirely without recourse. You are required to decide for yourself whether or not it is suitable for your purposes and no liability for loss of any nature can be entertained.
Let me present my problem in the right perspective. I have an existing MDI application in VB 6.0. There are around 20 forms right now. The Menu gives an option of 'New' to the user. According to the selection made by the User, he is displayed a form out of these 20. The number of these forms is increasing day by day which in turn increases the size of the Exe and the memory it takes up while running.
In order to address this problem, we decided to break up the Exe into smaller EXEs, i.e. one Exe for each form. So now when the User opens up the Application, he sees the MDI form. Upon selecting the required Form, the appropriate Exe would be called.
Here's where the problem sets in. Firstly, I am able to handle only one Form at a time. So this new application should also be running a single Form Exe at a time. Yes this contradicts my earlier question. In Word, you can open as many documents as you might want.
Secondly, each Form Exe would require the MDI Form to display the Menu etc to the User.
All this seemed to be quite logical before but I dont seem to find a way for its implementation. Please help.
Regards
Isha
Last edited by ishaaseja; Jan 6th, 2004 at 02:43 AM.
You have posted your question in the VB.Net section so I did not realise you are referring to VB6.
The main purpose of an MDI form is to allow the user to quickly see and locate the required child form. If you are going to have more than, say, 6 child forms surely the appearance is going to be very cluttered and is for all practical purposes to be avoided.
If the number of forms is increasing daily and you currently have 20, it seems as if the application has not been running very long. How many child forms are going to be necessary? What purpose is it intended that the proliferation of forms achieves?
I would guess that, if yours is a business application, it is something to do with the accessing of data collected on a daily basis. If so, using many forms is not the correct approach. The data should be called from the database table by one form giving location choice options - e.g. "Enter Date of Information Required" or "Enter Identity Code of Informantion Required".
Remember modern databases are quite capable of handling millions of records per table very quickly.
Taxes
The more I learn about VB.NET the more I like dBaseIII Plus
The foregoing, whilst believed to be correct, is given without guarantee as to it's accuracy and entirely without recourse. You are required to decide for yourself whether or not it is suitable for your purposes and no liability for loss of any nature can be entertained.
It has just occurred to me that perhaps what you should be doing is to use just one main form with one of the menu options being "Locate File" and then using the Open File Dialog Box to locate the file required. Surely the number of actions which can then take place is very limited and can be contained within one or two forms?
Taxes
The more I learn about VB.NET the more I like dBaseIII Plus
The foregoing, whilst believed to be correct, is given without guarantee as to it's accuracy and entirely without recourse. You are required to decide for yourself whether or not it is suitable for your purposes and no liability for loss of any nature can be entertained.
Just 20 forms ? I have near 80 forms in my VB6 project, and over that in the .net edition (classes rather then forms). Making them seperate .exe files will give you a HUGE headache when trying to control and pass information between them. One thing I did with my current project is to make DLLs instead, one DLL holds a controller class (that deals with loading the form INSIDE the DLL, and passing the control of it to the main MDI application) and the form itself. Everytime we want a new form (document type) we just copy a newly created DLL into a directory, and the main app picks up the file and asks it all the questions to know what and where to put it.
There are issues doing this, but it covers most things till we get it upgraded to .net later on, which is MUCH easier and far simpler to control.
I think your application is close to what I need in my application. The count of forms right now is 20 but would keep on increasing. The next release would have 42 forms.
I am thinking of migrating my Application to VB.NET as well as splitting it into DLLs/EXEs. Could you give me some more details about your implementation. I would be really grateful.
I have an MDI interface with just 1 form. This one form is empty, nothing on it at all. I load a class from a DLL using the CreateObject function. I then call a few functions in the class to set it up ready to show, for instance I give it the data to load. I then call another function inside the class, passing it a handle to an instance of the empty form. The class then creates the new form that I want to show, and moves all the controls over from its current form, into the empty one. I do that using SetParent API call. It looks and runs exactly like a form that is owned by the parent, you do get a few small issues like the focus is switched, and you cant click on the controls directly underneath forms, but it was the best method we found.
Menus are all added by hand (its horrid), using a formated string with keywords and descriptions.
Notes: You can only create classes from a DLL, you cant create the form directly.
You can actually just put the whole window from a DLL into your MDI, but you cant control it like the other windows. You dont get an entry in your MDI window list, and it changes focus to the other form like you switch applications, so modal windows dont work very well.
You need to know the name of the DLL to load, so all I did was add that into the resource file of the DLL at location 101. The main app tried to read that resource number (loading by filename using the API LoadLibrary function) and then once it got the name, it can create it using CreateObject.
Its a long old job, and hard to understand, but Ill help where I can. It took us months to arrange it to work properly, but it had to be this way. It covers 10 platforms (no one has even heard of) and client/server using .net, C++ and VB6.
-----------
In .net you can pass anything to anywhere (just about). Ive included a picture to show an adapted way, a mix between what I have now, and what I will do in .net. Apparently you can just load the assembly (the DLL) straight into your application, but Ive yet to learn how to do it. The example is just using form inheritance. The main app and the DLLs both reference the middle form (its the controlling form, standard function calls, saving loading etc). There is probly more ways in .net but Ive only used it for about a year and half, so still learning.
If the application is simply one of gathering daily information, it is not appropriate to create a new form every day!!!! Surely each day's information is to be accessed on the same basis? Even if there were several different bases of access one form could still easily accomplish this.
Stick with the principles used in Microsoft Word. If you want to save document type information, save it directly into a file using the SaveFileDialog box and access it using the OpenFileDialog box. If you want to save data, use a database -- that is what it is for!!
grimfort: I find it very difficult to envisage why you NEED 80 forms in one application - unless you are the chief programmer for a hugh multinational corporation trying to manage thousands of subsidiaries. As a matter of interest, what is the purpose of all the forms? Getting into the Guinnes Book of Records? Please do not take offence at this. If there is a good reason, I would like to know. (I am relatively new to OO programming but have spent a lifetime in business management - ranging from Barclays Bank to one man businesses). DOS based applications did use the equivalent of a large number of forms, forshadowing the "windows" concept, but that is entirely unnecessary in VB.net, or VB6.
I shall be interested to see what our Yankee cousins think of this when they wake up today!
Last edited by taxes; Jan 6th, 2004 at 08:07 AM.
Taxes
The more I learn about VB.NET the more I like dBaseIII Plus
The foregoing, whilst believed to be correct, is given without guarantee as to it's accuracy and entirely without recourse. You are required to decide for yourself whether or not it is suitable for your purposes and no liability for loss of any nature can be entertained.
My company deal mainly with large data centres (banks, councils etc), and is similair to Microsoft MOM and CA unicentre.
The application I work on has been under development for 4 years, with 4 full time programmers and a design artist. For a quick overview, the application communicates with multi-platforms such as unix, gcos, windows, SX3, anything that talks IP. Also databases. It has a few major parts using these communcations, such as
Job control: for mainframes, batch scheduling, load balancing
Alert management: watching NT event logs, system logs from unix, output logs from applications. Then actions such as email, text messaging, voice telephony, SNMP trap messages.
Environment monitoring: We have devices to measure temperature, humidity, light, power, water and anything else you can stick in a basic I/O device.
Message management: Reading console messages such as out of paper, low disk space, incorrect logins. Is used alongside alerting.
We are a major player in the market and its a large project.
In answer to your question, why 80 forms (its actually about 65, just counted ). Thats just in the desktop (a view to control all the above), theres just hundereds of different configurations for all the devices and platforms, not to mention the inbuild report and graph designer, data selection screens. A lot of forms have been reused where similar, so not much duplication. Many home made controls to also help stop duplication.
There are at least another 40-80 forms inside the DLLs, which are loaded in both VB6 and VB.net.
One interview I went to many years ago, was for programming an accounting system in VB6, that had well over 150 forms.
Ahhhh! I was not far wrong, was I? Nice site of yours.
I still think that forms are for interfacing with the customer and that modules should be used for the guts of the application. But I agree, you are in the forefront of marketing applications and are probably more aware than I am of what the customer wants. I am surprised you chose to write your programmes in VB6. It gives me hope that my decision to move to VB.NET from my previous DOS environment was correct - I see so many comments that VB.NET will be abandoned in the not too distant future.
However, it seems to me that you are talking of a totally different application than that refered to by ishaaseja. His application seems to require that the customer creates additional new forms every day which he/she seems to consider should all be available live at any time. I just cannot see why.
Taxes
The more I learn about VB.NET the more I like dBaseIII Plus
The foregoing, whilst believed to be correct, is given without guarantee as to it's accuracy and entirely without recourse. You are required to decide for yourself whether or not it is suitable for your purposes and no liability for loss of any nature can be entertained.
The number of these forms is increasing day by day which in turn increases the size of the Exe and the memory it takes up while running
He did not mean, one new form gets created everyday, just that he has to add new forms every so often. At least, thats how I read it.
With word, its the same document type every time, in my app, each DLL holds a different document type, ones a graphing object, ones a report, another a message list etc etc..
You may well be right. We will have to see what he says. Presumeably he has gone to bed by now.
Thanks for your input.
Taxes
The more I learn about VB.NET the more I like dBaseIII Plus
The foregoing, whilst believed to be correct, is given without guarantee as to it's accuracy and entirely without recourse. You are required to decide for yourself whether or not it is suitable for your purposes and no liability for loss of any nature can be entertained.
I see a lot of disussion follwed after me leaving the office
I'll try to explain the reason for including new forms in my application so often. Taxes, its not that I have to add new forms everyday. Its more like what Grimfort understood it to be.
My application is meant for the US Insurance Industry. Any person going for Insurance has to fill up a lot of ACORD(Its a body that prepares standards for Insurance Industry) forms. These forms are available on the ACORD Site in PDF Format. You can always take a printout and manually fill it. However to fill it electronically requires you to have PDF Writer.
So we decided to come up with an application that allows you to fill up the Forms electronically, validate the Data that you filled in, save it and even e-mail it. To accomplish this, we used one VB Form for each ACORD Form available. WMF file for the ACORD form is used to provide the text and textboxes on the Form are used to contain the data entered by the user.
Now, as the request comes to add a new ACORD Form, I have to add a new Form.
Thats all for my explanation.
And yes Grimfort, you are again correct in saying that my application is unlike word as Word contains all the similar Document types but all ACORD Forms are different.
Regards
Isha
Last edited by ishaaseja; Jan 7th, 2004 at 04:33 AM.
Probably my brain is still on holiday but what you are saying still does not make commercial sense to me.
How many DIFFERENT CONTENT forms does ACORD require? I do not mean how many applications are completed. Surely that number is finite and known when you designed the application? I cannot imagine that there are more than a dozen different types of form (remembering that differences which depend on answers to certain questions can be easily accommodated in the same form.
If you are having to continually add new forms (VB.Net style that is) to your application on a regular basis, it seems to me that your Systems Analyst has fallen short on his/her job.
Have you considered creating your own library of Acord forms on your own web site, updating it as required, having written in a procedure in your distributed applications which will regularly access your site for updating? Provided each of your clients has a separate identity code, your library can ensure that only appropriate clients will receive the update.
Otherwise it looks like grimfort's approach will solve your problem.
Regards,
Regards,
Last edited by taxes; Jan 7th, 2004 at 06:17 AM.
Taxes
The more I learn about VB.NET the more I like dBaseIII Plus
The foregoing, whilst believed to be correct, is given without guarantee as to it's accuracy and entirely without recourse. You are required to decide for yourself whether or not it is suitable for your purposes and no liability for loss of any nature can be entertained.
How many DIFFERENT CONTENT forms does ACORD require?
Currently ACORD has around 800 forms(a rough idea). And they also keep on introducing new Forms as the Standards evolve. Further, this is the upper limit that I might some day reach. But right now, I am supposed to include only those forms which my Customers require. Thats 45 right now.
If you are having to continually add new forms (VB.Net style that is) to your application on a regular basis, it seems to me that your Systems Analyst has fallen short on his/her job.
When the requirement came up, we were not very sure that the number would increase further. We just developed an application that acommodated 19 forms. In a way we are trying to redesign the application so that the this requirement can be met.
It does occur to me that there is some confusion here over the word "Form". "Form" in relation to that which is filled in by an applicant is really a record in a data file and is more or less permanent in it's existence.
As I discussed earlier, my Application works like Word. You create a new ACORD Form, its like making a new Word Document. You choose an ACORD Form type from the list of available ACORD Forms, its like selecting the type of Word Document you want to create. You fill in the data, its like writing something on the Doc. After that you try to save the ACORD Form. Saving the ACORD Form involves preserving the data that the user filled onto the ACORD Form, but not in a database. It saves the data of the ACORD Form as a name-value pair, where name is the Index of the Textbox and Value is the value contained in the textbox in a text format using a SaveDialog box. So its just like saving you Word Doc on the Hard Disk.
"Form" VB style is an interface through which the applicant communicates his data and very quickly reverts to it's original impersonal state.
I am using the VB Forms to simulate the ACORD Forms by using an image File and superimposing Textboxes on it.
I have tried to be clearer this time. Please let me know if you still feel something is bad with this design. I am open to all kind of suggestions.
Well, now this may be a different kettle of fish.
How do you fancy making this with just 1 form ?
Heres the design items that you have mentioned so far:
Input from an existing image (WMF possibly ?)
Captions and textboxes (do you have checkboxes and date controls ?)
Key Pair values
Output via file
If you can change the input to a formatted file, then use the formatted file to create a dynamic form. If you HAVE to use the image then the design will have to be different, but you can still do it. So, the new design plan could be as follows:
1) User opens a form (its a file with the setup definition).
2) The file is read in, and split down into its questions, being a caption and its type (if you need checkboxes or options).
3) A form is created using this set of questions, a new lablel to hold the question, and a new text box (or checkbox) to hold the value.
4) User enters the data
5) User presses save
6) Form loops through all the controls on the form, and gets the values from them, using the key pair idea. And is then saved to disk.
Each form is just a new text file with the relavant questions loaded into a dynamic loading, your time is then spent on creating these text files, rather then forms. Each time you have an update, you just email out the new text files and they copy to the correct directory, and the software automatically picks it up.
So 1 form, many text files.
I can probly make it in 30 mins if you can supply a 2 or 3 forms, and the format you need it output as. There are other design issues, but the basic idea can be implimented fairly easy.
It is not a question of whether a programme is badly designed or not. We all have to work with what we feel is comfortable. I grew up with Dos type programmes where the use of a database was the only practical alternative, so I tend to stick with that approach.
I find it incredible that Acord has so many different forms. The insurance industry has two basic branches: Life and General but both require several common items of information, e.g. name, address, date of birth, initial health questions etc., so there can be one common base class.
Thereafter, all Life business requires several common items, e.g. detailed health, family history and this should be incorporated into a derived class. You could then possibly use a one further derived class for each life category, e.g. annuities, life policies, investment, but from then on the form could contain all the required questions, revealing the appropriate ones as each question is answered. E.G. If the answere to "Married" is "Yes" the the form reveals the appropriate partner related questions.
Similarly with General Insurance.
The above would apply to the regulatory forms to which you are obviously referring.
It does seem that you are VB6 orientated and I wonder if you have explored Inheritance in VB.Net fully yet. This will save you a lot of work in your type of application. You will note from grimfort's remarks that he expects things to be much easier in VB.Net. Also, you should consider developing a web site to ease your communication with clients.
I do not envy you in your task!
Regards,
Taxes
The more I learn about VB.NET the more I like dBaseIII Plus
The foregoing, whilst believed to be correct, is given without guarantee as to it's accuracy and entirely without recourse. You are required to decide for yourself whether or not it is suitable for your purposes and no liability for loss of any nature can be entertained.
Reply With Quote
.
