|
led mike wrote: Must Type Code.... loop... while... switch ....
real coder doesn't use loops 
|
|
|
|
|
darkelv wrote:
real coder doesn't use loops
I don't know, there are LOOP instructions in x86 assembler? 
led mike
|
|
|
|
|
I have no problem typing code. I am just trying to establish the best way to accomplish such an app. I thought tabs would work but it's going to be very big. It also is currently taking about 3 seconds to load. I am not sure if it's the dataset that is slowing it down, or the controls. Considering though that I haven't really changed the dataset, but I have added many controls, I am assuming that it's the controls that are taking a long time to load. Is there any way to make the tabs load only the controls on the tab that is open? Now I was thinking that I could do many forms, but that would be quite a bit of work. And it would mean that I would have like a zillion forms in my app. Please someone give me so clear direction here before it gets too late in my app and will be even more difficult to change it.
|
|
|
|
|
Controls are very expensive to create, so the more controls you put on a form, the more the form code has to create upon instantiation and the longer the form takes to create. This will happen regardless of which tab the controls are on. There is no way to design everything and then tell the code to just create this set of controls. It's all or nothing. Lesson: Keep the number of controls you put on a form to a MINIMUM.
Like you were told, you create a dynamic user interface that is driven by data comming from a database. Every approach your mentioning will result in an app that takes quite a long time to write, is difficult to maintain, and as mentioned, requires you to do way too much to add a question to it.
|
|
|
|
|
So what is the recommended path to take because right now I have a lot of work ahead of me and no direction. If I could just decide which way to go I could implement it. I should let you know that I am thinking to just make a lot of small forms connected at the main form where when a next button is clicked, the form will close and a new one will open. Also, if there was a new item to be added later, then I could just insert a new form and change the code a little. I would be open to dynamically creating the controls, but correct me if I am wrong, but I would have to basically manually code all of my controls which would be veeeery time consuming. These controls are varying in size so it's not as if I could say put 5 on each page. There are some questions where they type it into a text box and other that have many radio buttons as well as check boxes. Not to mention if let's say one would fit on a page if I just moved it up one pixel then the code would not do this. Anyways I know c# and winforms but I have never come across this kind of dilemma before and if someone could just point me in the right direction so I can move forward with this.
|
|
|
|
|
bfis108137 wrote: I should let you know that I am thinking to just make a lot of small forms connected at the main form where when a next button is clicked, the form will close and a new one will open. Also, if there was a new item to be added later, then I could just insert a new form and change the code a little.
What did I say?? You do NOT do this. You make a single form that can display any question you want, then you just feed this form the data and it takes care of displaying it. You're going about this all wrong and can't seem to break from it and see that there is a much simpler solution.
You may not have a single form to display all types of questions. You may have to code a different form for each question type.
|
|
|
|
|
Dave Kreskowiak wrote: What did I say??
Told you. 
led mike
|
|
|
|
|
First of all, in the end isn't this going to actually take more time?? Secondly, I cannot play with the order. This is a legal thing. Thirdly, most of the questions are simple either a text answer or multiple choice, but there are some that just really complicated that include basically many parts that are more or less like all of the types. And if it doesn't come out all together on the form, then it won't even make sense. That could be as much as 10 parts. The more I think about it the more I think that maybe it might be easier but I am at a loss as to how to implement it. Do you have any examples? I have searched all over the net for some code examples for this kind of program and have found nothing.
|
|
|
|
|
Dave Kreskowiak wrote: Controls are very expensive to create
Hence why I told him earlier to simplify the task at hand. 
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
|
|
|
|
|
Hence why I never bothered replying to him. See your John Simmons quote.
led mike
|
|
|
|
|
led mike wrote: See your John Simmons quote
Yep. That's why I have it. So I always remember it
I love the looks I get from people when I use that sig. They stop, process for some certain amount of time, then finally laugh. I wonder what goes on during the delayed laughs.
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
|
|
|
|
|
Dave Kreskowiak wrote: Lesson: Keep the number of controls you put on a form to a MINIMUM.
Lesson: If you have to explain that to someone, nuf said.
led mike
|
|
|
|
|
So in that case I would not be able to use the designer to create my controls correct?
|
|
|
|
|
Not directly, yeah.
I can understand that you may have time and resource constraint. You can take that idea a few steps back:
1. Generalize the questions as much as possible into few types of question.
2. Create custom controls for each type of question. Expose methods/properties to set the question text, options etc.
3. Have a "Question" table or resource file that store those text for each question.
4. Have a "template" table that store Page Number, Question Order, Question Number and their associated question type in (1).
5. On displaying the questions for certain page, pull the data from template table, create the custom control base on the question type, populate the text from question table and bind/associate it with your dataset for answer updating, put them in a panel or TableFlowLayout control for display.
6. Repeat (5)when user change the page.
|
|
|
|
|
That sounds incredibly complicated. I know how to program this stuff but I am still relatively new. I rely mostly on the designer to create my controls. Do you have an example of where this was implemented. If I just put them on separate forms, I would just lose updating flexibility right?? Also why do I have to have a question type?? The order is predetermined. I cannot play with it, although it is likely that questions will be deleted, added, or changed. Also could I do it the easy way and then somehow use the code later in the new format?
|
|
|
|
|
Hi,
if a database-driven or table-driven approach seems too complex, I suggest you do the following:
- create a separate Form for each question, any way you choose (say Visual Designer);
give them all the same Size, and probably no border at all, no Close/Minimize/Maximize/SystemBox.
- create a main Form, which holds:
- a Panel (say questionPanel) with the same size as your question Forms;
- a "Previous" and a "Next" Button;
- whatever else you deem necessary.
- provide a Form variable, lets call it currentQuestionForm, initially null.
Now to show a question, this is what your code should do:
- remove the previous question (i.e. undo what follows for the old question); this includes:
- assuming currentQuestionForm is not null:
- removing it from the questionPanel.Controls collection
- set currentQuestionForm=null;
- add the new question by showing newQyestionForm:
- set currentQuestionForm=newQyestionForm
- setting its currentQuestionForm.TopLevel property false
- setting its Location to (0,0)
- adding it to the questionPanel.Controls collection
This way, your question forms live independently, and never get loaded at the same time, keeping
performance OK.
|
|
|
|
|
bfis108137 wrote: The order is predetermined. I cannot play with it
The order is not for you to play with, it's for the user to add, remove, rearrange.
bfis108137 wrote: Also could I do it the easy way and then somehow use the code later in the new format
Yes you can redo the system later on, it will just bite you back in the end, hard. But because now that you have a working application, the user will not want you to redo it because of time and effort, unless you have a really really good reason.
I have seen application that started with "keep it simple cos we want the system as soon as possible" requirement from user and eventually it expanded until the original (non)design became a obstacle for the expansion.
Anyway we are not forcing you to do it certain way. You should present the options to the user/owner about the effort needed and the flexibilities. If they still want the "simple way", let them know that maintaining it later will cost them more.
|
|
|
|
|
Does anyone have any coded c# examples of how this would be implemented?? and once again you guys are suggesting that I store my controls in a database basically right??
|
|
|
|
|
Hi, my reply, three up right now, works fine without a database. It uses what I would call "forms in forms".
|
|
|
|
|
What if I created a standard panel size that would be big enough to fit any 1 question into it, and I stored the panels in a collection, and then serialized the collection. Would the panels in the collection hold all the controls within it, or would it just hold the panel?
|
|
|
|
|
Hi,
if this is as a response to my earlier suggestion (with Form.TopLevel set false), then:
1. why serialize things, I never mentioned that.
2. I'm not a serializing expert, but I don't expect the Collection of Panels to automatically
keep all its Panel contents.
3. a Control (such as a Panel or a Form) that holds other Controls, can be included inside another
Control (such as a Panel or a Form), and by doing so it remains the parent of all the Controls it
was holding; basically you can build Control hierarchies the same way you build file/folder
hierarchies in a file system.
|
|
|
|
|
Hope someone can help. My problem is that the appearance of the buttons is different when I launch the application after I do a Windows Install. When executing from Visual Studio, the individual buttons are not shown. After installing from an msi file (both on my and other computers), the GUI changes. When I start the application from the installed map (c://programFiles), the buttons are changed. I know that this is not caused by any of the dlls in the install map (since I copied them from my own map by hand to test this). When I changed the name of the application in the install map (c://programFiles) then the buttons look as they should. So, there must be some connection between some data base and the application which causes this to happen (and this connection is somehow dependent on the original name of the application). How, can I prevent this from happening? Is this some sort of a bug in VS? Vista?
I am using VS 2005 for .net on Vista, working with Windows Forms, and using C#.
Have been surfing the net like a madman to no avail so Any ideas? anyone?
Katalin
|
|
|
|
|
Welcome to Code Project ![Beer | [beer]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/beer.gif)
Katalin21 wrote: So, there must be some connection between some data base and the application
A Database? No, the only connection to a Database would be one the developers created. Nothing in Windows or .NET or Windows Installer is going to generate some undesired-unknown connection to a Database the developers are not even aware of, period.
Katalin21 wrote: When I changed the name of the application in the install map
I am not familiar with the term "install map" and a google search is not finding it either. Are you making that up? Don't make up your own terminology for posting in forums, people will not understand what you are talking about. Read and study the technology you are working with so you can use the terminology that people will understand.
led mike
|
|
|
|
|
Hi again,
What I meant by "install map" is the place to which the msi file will install the application. In most cases (as in mine) the default is usually to the "Program Files" map. And no I don't know for sure that there is some sort of connection between the name of the installed application and some sort of install data base (possibly the msi file) but that seems like a logical conclusion since the application behaves as it should when I change its name in the map where it installs under c://program files.
My question is: how do I prevent this behaviour (the changed appearance of the buttons) since it would not be reasonable to ask the user to change the name of the application after installation?
Best Regards,
Katalin
|
|
|
|
|
Katalin21 wrote: What I meant by "install map" is the place to which the msi file will install the application. In most cases (as in mine) the default is usually to the "Program Files" map.
folder. That's the word you are substituting with "map". Program Files is a folder, not a map.
Katalin21 wrote: there is some sort of connection between the name of the installed application and some sort of install data base (possibly the msi file)
Well an MSI file is a database, but no your application has no "connection" to it. Unless of course you are not talking about a Database Connection[^] and we are having a terminology communications problem like with folder and map. The Windows Installer runtime uses the MSI database to perform the installation.
Also what do you mean by the "name of the installed application"? Are you talking about the executable file name? MyApplication.exe
led mike
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
