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

Events code firing and screen display ? 2

Status
Not open for further replies.

ramani

Programmer
Mar 15, 2001
4,336
AE
When I put code which does some heavy processing of tables.. I show a container holding message at the top of other controls in the form. Then do the processing.. then clear the container.

In fact, my base form has the container (message holder), and whenever a message need to be put.. it is turned on with
MessageContainer.cMessage.Caption = myMessage
MessageContainer.Visible = .t.
That shows up at the middle of the form.
When the processing is over..
MessageContainer.Visible = .f. turns off the message.

The whole thing goes fine.

Now the problem....
Sometimes and in some user units I notice .. the message container refusing to show up until after the processing (which is put in code after the above code).. is over... either complete or a resonably over 50% or even 75% is over.. then shows up for few seconds until the natural hiding of that fires up.

On the whole, if the process takes .. let us say.. 5 seconds.. and the message container is supposed to be on top for 5 seconds.. it shows up for the last 2 seconds or so. There is no other error and everything is fine except the delay in show of message.

Could any one tell .. what is holding up and what could eliminate that.

My own trial/expriments done..
If a wait message put after the message and before processing.. firing is instantaneous. SO that makes me think.. the code is fired even before the screen is refreshed by OS.. and in that split second.. vfp processing continues with next line code..occupies the processor .. and when the cycle releases for another hardware avtivity.. screen refresh takes place showing up the window.
[Wait window codes fire extremely fast compared to own message container refreshing. So the wait messages appear faster rather than showing container.]

Can any one else help me with better insight on this subject. Thanks ahead for your valuble time. :)
ramani :)
(Subramanian.G),FoxAcc, ramani_g@yahoo.com

 
Ramani

I have found that it is dependant on the OS, the amount of RAM, the speed of the hardisk, the screen refresh rate etc...Mostly unrelated to VFP. I have encountered that in some cases my message form also decides to show up "when the processor has a bit of power to spare, in order to show the form.". After many trials, I have reverted to wait windows as you say "If a wait message put after the message and before processing.. firing is instantaneous.". Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.
 
Thanks Mike for conforming with my findings.
I dont know if I will succeed, but want to make my MESSAGE container to do something in such a way that it gets displayed first and then the processing to continue. Let me hope that I find a solution.

As a finding.. only the display is not completed.. but the processing is surely over long back before the screen shows that. :)

The reason, I want to acomplish this is that my message container can play AVIs and so nice visual impacts can be delivered without impairing speed. But the above reality is giving me doubts about performance.

:) ramani :)
(Subramanian.G),FoxAcc, ramani_g@yahoo.com

 
ramani

May not be strictly relevant to your situation, but I find if you are processing within a SCAN..ENDSCAN or similar loop and need to effectively 'refresh' a label caption or progressbar, in your case a message container, INKEY(0.1) will pause program execution just long enough for the pseudo refresh to take place without having a serious impact on performance.
FAQ184-2483 - the answer to getting answered.​
Chris [pc2]
 
Ramani

Are you using a class message form?
Any way to check to see if the form is an actual object, and visible before running your SQL. I'm not sure if it would make any difference.
Code:
PUBLIC oMessage 
LOCAL lShow
oMessage=CREATEOBJECT("form")
lShow = oMessage.show
IF VARTYPE('oMESSAGE') # "O" or !lShow
  **don't run the sql yet
   oMessage.show()
ENDIF
Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.
 
Hi Mike,

As explained, the whole code got fired but the CPU was so much occupied with the subsequent code firing sequence.. the display was forced to wait. And in a machine of Athlon XP 2 GHZ and in Intel 2 ghz with 512 MB RD RAM 80 GB High spee harddisk with over 20 GB free space in the selected partition.. whatever.. I cannot think of hardware limitations. But something 'in' there that VFP firing fast is holding the screen refresh and that seems obvious. Something like SYS(3) of FP2.6 days in fast computers.

However.. Chris idea is nice. In fact I just put
INKEY(0.001) and the display was instantaneous. Since this is a class in my very base form.. all the forms now respond with its quickness. The rest of AVI.. different systems etc.. I have to test subsequently.

Thanks Mike for your time and added star to you Chris for the flash of an idea.

:) ramani :)
(Subramanian.G),FoxAcc, ramani_g@yahoo.com

 
Hi,

Thanks you for this discussion. I have stayed away from much screen maniplation for the sake of visual impact simply because of the problem discussed here. The little 'Inkey' trick works great.

Absolutely, Thank you.
WJS

 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top