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 Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Ideas for a Splash Screen?

Status
Not open for further replies.

David Higgs

Programmer
May 6, 2012
390
GB
Looking for some ideas on how to provide a "Splash Screen" for my application(s) whilst it's initialising. Nothing too fussy, just a message showing that the program is running. My main form Logbook.SCX is currently a 'Modeless', 'Top Level Form'.

Code:
*                      
*	Display Main Form  
*	-----------------  
		
DO FORM Logbook WITH tcCallsign

READ EVENTS

Regards,

David

Recreational Developer and End User of VFP for my personal use in 'Amateur Radio' and 'British Railways' related Applications.
 
David,

I hope you already got things going, if not, let me ask one important question, is your main.prg just called that by file name, or is it actually the main item in the project you use to build the EXE? It must appear as the only bold item of the whole project and if you right-cliick on in must have a check at the context menu item "Set main". Otherwise, something else might be calling your main.prg but runs first and takes time.

Another way I think the messages appear now that you show a splash screen is that the initialization phase of your logbook.scx has something in it that uses "?" or other commands to print on whatever is the currently active form. And that didn't show up before, as you don't have the _screen or anything else visible. So you may see messages you never saw before just because the splash screen now does allow these messages to appear. The Logbook.scx form only shows after its Load() and the dataenvironment and Init() have run and the form is finally shown, which causes it to be refreshed, so any message that was written onto it does get cleared from it.

Just one possible theory, As I don't have hands on your project it's hard to tell what's actually going on.

The dataenvironment of the Logbook is where you likely spend most of the time before the logbook form shows. If you defined views which just do a [tt]SELECT * FROM mysqltable[/tt], for example, it will take longer and longer the more data you have, not like putting in DBFs that correspond to a USE of the DBFs, which each only need split seconds, no matter how much data is in a dbf. A view that selects all data, actually does that. A USE only does to a DBF what a USE does: A table header validation, positioning on the top record according to the order you specify or by lowest recno. You only have that luxury with DBFs, not with a remote database. Even if the MySQL server runs on the same computer as localhost it takes a bit to load the data from it into your view workareas.

You can make it as fast again if you configure the views in the dataenvironment objects to nodoataonload=.t. But then you still have a difference to the USE of a DBF: You have no record in the workareas.

Sorry, if all that does not apply, as I am only assuming you use the dataenvironment and remote views to your MySQL data. It still applies in almost the same way, if instead, you put cursor adapters into the dataenvironment of the Logbook form, but that seems even less likely to me. It won't apply at all if your Logbook form does not make use of its data environment, of course, but then the question is what else causes such "executing remote" messages. It's surely not the splash screen only showing an image or a label with a message, it's surely not the general startup of the Visual Foxpro runtime any VFP EXE has, as that load of the runtime DLLs goes without any message at all. It's somewhere in your own code or DBC or MySQL usage or any class libraries or application framework you use for that.

Chriss
 
Chris Miller said:
I hope you already got things going, if not, let me ask one important question, is your main.prg just called that by file name, or is it actually the main item in the project you use to build the EXE? It must appear as the only bold item of the whole project and if you right-click on in must have a check at the context menu item "Set main".

Yes Chris, the main.prg (actually called "Amateur Radio Logging Program.PRG") is SET MAIN

To further expand / clarify on my previous posts:

I found the "Executing Remote - Press escape to cancel" message is being generated during the opening of MySQL Table(s), SET ESCAPE OFF suppresses the messages.

I created a simple form (SplashScreen) with VFP IDE and placed a label and a timer on the form, ShowWindow = 2 as Chris described and this is running as expected.

(1) The first line of my application has LPARAMETERS which receives a Command Line Parameter passed from a Desktop 'Shortcut' this determines which Databases should be used.

(2) I then SET PATHS / VFP Configuration

(3) DO FORM SplashScreen

(4) Initialize MySQL Settings, Open / Load Databases

(5) DO Main_Form.SCX

Chris Miller said:
The dataenvironment of the Logbook is where you likely spend most of the time before the logbook form shows. If you defined views which just do a SELECT * FROM mysqltable, for example, it will take longer and longer the more data you have, not like putting in DBFs that correspond to a USE of the DBFs, which each only need split seconds, no matter how much data is in a dbf.

I think you've hit the nail on the head there, I found the issue of the delay before the Main_Form.SCX is displayed is due to item (4) above. I need to take a look at the Main.PRG to see if I can optimise the Opening / Loading of Databases in order to reduce the delay of displaying the main_Form.SCX I will take on board your comments and Gerrit's.



Regards,

David

Recreational Developer and End User of VFP for my personal use in 'Amateur Radio' and 'British Railways' related Applications.
 
David,

that seems very okay to me, how fast does the splash screen show after you start your EXE? I currently have an SSD that could need a TRIM to get faster, and it takes quite a while before my application shows. But aside from my problem, I don't think your point (2) will take very long, if it's not necessary for the splash screen to work, you could swap (2) and (3). A DO FORM done within an EXE will always find the form inside the EXE, no matter if you configure the right default path or not. And by the way the default path can also be set by the shortcut you also use to pass in the parameter.

I don't ever heard that opening a mysql table would cause that message and the only help topic that comes up if you search the help for just the part "Press escape to cancel" is within SET REPROCESS when a lock is attempted. But that's neither done remote nor is it about a remote database. You also don't find "Executing Remote" as term, you of couse find the wors execute/executing and remote. But that message has to come from your own code.





Chriss
 
I looked into what code is generated by the cursor adapter builder, well I should have searched here in the forum.

This message comes from using remote views according to thread184-390026
So you do use remote views.

Likely you just created views that have the query SELECT * FROM TABLE. Well, that's deadly for your performance.

Chriss
 
Chris,
Chris Miller said:
how fast does the splash screen show after you start your EXE?

Initially the SplashScreen (just the form) appears within a second, after about 3 seconds the Forms 'Label' appears and the backcolor changes color and then finally the LogbookScreen appears after about 6 Seconds. In the scheme of things not much of a delay but a message showing that the program is running would be be reassuring.

Likely you just created views that have the query SELECT * FROM TABLE. Well, that's deadly for your performance.

That is where the delay is taking place for sure.

The reason for going down the MySQL Path was to be able to access the database on a LAN and to be able to share the data with third-party applications.



Regards,

David

Recreational Developer and End User of VFP for my personal use in 'Amateur Radio' and 'British Railways' related Applications.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top