If It can help to someone, this is I always do: When I'm going to open a form, I always call my own OpenForm(FormName as String, Parameters as String) sub. This sub is not inside the form I'm going to open. It's a public sub that's is inside a utilities module.
OpenForm() sub create new object with the form (f.e. FRMMain) and put its reference inside a public collection called OpenedForms. Before to show form to the user, I show other form with a progress bar and a label showing "Loading..." and I'm going executing SQL, show/hid controls, etc... with no show anything. If there are a fixed steps to data load, I updated progress bar and when load process finish I show the form. I use this in all my apps (since lot of years when I never eared about gambas and I was programing in VB, Access, Java, etc...) and for me is the best option. For sure there is a lot of ways to do this. Regards, Ricardo Díaz 2010/4/13 Doriano Blengino <doriano.bleng...@fastwebnet.it> > Fabien Bodard ha scritto: > > 2010/4/13 Doriano Blengino <doriano.bleng...@fastwebnet.it>: > > > >> Fabien Bodard ha scritto: > >> > >>> just remember to put a flag to say when the data are loaded ! > >>> > >>> > >> What would be the reason for this flag? > >> > > if the form is showed and the data not accessible ? > > > Really, there could be a problem if the user clicks a button 50 ms after > the button (and the whole form) is visible. A remote possibility, and > application-dependent. But I know users enough to imagine that someone > could do it... :-) > > Reducing the interval of the one-shot timer can help, but does not solve > (interval=0 could?). The better way is to disable actions the user could > do with invalid data (application dependent: who says that the form is > intended to receive clicks?), and perhaps add a nice label stating > "Loading data, please wait..." and so on. > > Anyway, the flag is the worse solution. Supposing you use a flag, and > the user clicks or types too fast, what would you do? A > Message.Info("You clicked too fast. Go to have a coffee and come back > later.")? :-) Better to disable some controls, so the user is informed > before; in addition, controls are already "global variables" which carry > informations with them. Well, this is my opinion - I hate to duplicate > informations around, but someone else on this list, time ago, said > "never use the GUI to store information". The problem with global (or > class) variables is that you can forget them more easily than some > property of a visible control. > > Regards, > Doriano > > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Gambas-user mailing list > Gambas-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/gambas-user > ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user