[Gambas-user] Showing the Form's Gui

richard terry rterry at ...1946...
Thu Apr 15 11:41:22 CEST 2010


On Thursday 15 April 2010 08:07:56 Fabien Bodard wrote:

The method suggested using the timer works for my use really well, and really 
simply. 

Users are much more tolerant if the gui is showing and processing going on in 
the background even if the busy cursor is showing briefly.

This particular form in my program is a document inbox - where incoming 
messages - ranging from hl7 messages to scanned documents or internal messages 
have ended up in the users  inbox. 

As it will usually only have a dozen or so entries a day, timing is not a 
ususally problem.

Just for interest I loaded it with parsed messages, containing documents for 
160 patients/640 odd documents, with 45,000 individual components to construct 
the  documents final html (many were pathology reports hence granular in 
nature)  and it took 1.6 seconds from postgres in yet to be indexed tables.

Nothing needing to be done prior to  loading. 

The delay in the gambas gui appearing is an interesting question, as in some 
other forms involving no such processing, loading is also slow - must 
investigate.


Regards

richard

> i don't know if richard want the user to be able to do anything on the
> showed form before the tatal loading ...
> 
> 
> the better way will be to do the loading in the timer by use the
> timer.trigger function
> 
> the form .enabled will be set to false
> 
> and the timer just set the form.enabled to true when the loading is ok
> 
> when you set a contained enabled to false all the form content is set
> to false too. So the form is showed but not editable.
> 
> 2010/4/13 Doriano Blengino <doriano.blengino at ...1909...>:
> > Fabien Bodard ha scritto:
> >> 2010/4/13 Doriano Blengino <doriano.blengino at ...1909...>:
> >>> 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 at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gambas-user
> 




More information about the User mailing list