Skip to main content

Displaying a Progress bar that doesn't affect your program

I have been really intrigued by the MTmyVFP project on Codeplex - primarily because I want my FoxPro apps to be as efficient as possible and to run in the background where possible but one of my pet peeves in a recent application is that if I'm doing some heavy work and want to display an animation (similar to the Copy files that you see in Windows), the animation really gets bogged down with the processing.

As a result, it looks funky to the user. I had asked Claude Fox if MTmyVFP could be used to do this - and the answer was to make my processing code run in the background and then make the animation run in the main application thread.

That wasn't doable but it made me think: what if I had an application that could show the animation and then I would just call it when needed.

Here's how I did it in VFP:


DEFINE CLASS oAni AS Custom OLEPUBLIC

oForm = .NULL.


PROCEDURE Show (tcTitle,tcAvi)

THIS.oForm = CREATEOBJECT("frmanimation",tcTitle,tcAvi)


THIS.oform.Show()



ENDPROC


PROCEDURE Hide

THIS.oForm.Release()

ENDPROC

ENDDEFINE




DEFINE CLASS frmanimation AS form



Height = 106

Width = 377

ShowWindow = 2

DoCreate = .T.

AutoCenter = .T.

Caption = "Working"

ControlBox = .F.

AlwaysOnTop = .T.

Name = "frmAnimation"



PROCEDURE Init
LPARAMETERS tcTitle, tcFile

IF EMPTY(tcTitle)
tcTitle = ""
ENDIF

THIS.Caption = tcTitle
THIS.AddAnimation()
IF EMPTY(tcFile)
tcFile = "filemove.avi"
ENDIF
LOCAL llRet
llRet = .T.
LOCAL lcErr
lcErr = ON("ERROR")
ON ERROR llRet = .F.
IF FILE(tcFile)
THIS.Avi.Open(tcFile)
THIS.Avi.Play()
ENDIF
on error &lcErr
RETURN llRet
ENDPROC

PROCEDURE AddAnimation
THIS.AddObject("AVI","olecontrol","comctl2.animation.1")
WITH THIS.Avi
.Top = 3
.Left = 0
.Height = 100
.Width = 372
.Visible = .T.
ENDWITH
ENDPROC
PROCEDURE Error
LPARAMETERS nError, cMethod, nLine

** Ignore it
ENDPROC


ENDDEFINE
*
*-- EndDefine: frmanimation
**************************************************


Then build the code as an EXE. I called mine THERM.

Now, whenever you need to show a thermometer, you can call

lo = CREATEOBJECT("Therm.oani")
lo.Show("Working","FILECOPY.AVI")

(hint: you can find AVI files in the VFP Home Directory under Graphics\Videos.)

Your progress bar will appear right in the middle of the screen.  Now when you need to close it, just call:

 lo.Hide()

You can take this even further by changing the form details with THIS.oForm.Caption, etc, etc.

The only downside here is that you HAVE to register your EXE so you can instantiate it but you can do that easily simply by running it once with a REGSERVER.

Now, of course, there is a GOTCHA and that is that if you run this class, you may notice a weird transparent background every now and then.

The solution? Forget using a non-visual class. Instead, create a form with the same code and drop the control on it to begin with.

For good measure, set the Center property of the Animation control to .T.

Then you're even BETTER to go.

So in my class, instead of doing the CREATEOBJECT, I simply call

PROCEDURE Show (tcTitle,tcAvi)

DO FORM DispAni WITH tcTitle,tcAVI NAME THIS.oForm



ENDPROC



The end result is a much smoother animation while your application does all its work.


Powered by ScribeFire.

Comments

Unknown said…
I did something similar a while back, but I used a free table to store the progress state. In my processing application, I would simply update the values in the table, there was no need for the programs to interact.

create table status ( ;
title c(50), message c(100), ;
percent n(3,0), paused l, cancelled l ;
)
append blank

The progress app contained a pause button which would lock the single record table and a cancel button.
Andrew MacNeill said…
Cool idea, Brian.

In my case, I didn't want to show a Thermometer persay but rather the animation (maybe I should have changed the title of my post).

We already have a thermometer showing at the bottom of the screen which updates every 200 records.

But that's definitely a useful approach as well.
Unknown said…
I was eventually planning on sticking the progress application in the system tray, never got the time to do it.

The last time I tried putting an application in the system tray (using VFP8 and Binding) it was so buggy that I ditched the idea.

I'm hoping that VFP9 has better support for this sort of thing. Alternatively, a C# or VB app that uses ODBC to read the status.dbf table would probably be easier to stick in the system tray.
Anonymous said…
The Ole control seem to run unly file from disk.

I've tried to run the AVI file that were include in my Project without success.

Any tips?

Popular posts from this blog

Blogs and RSS come to Microsoft.com

MS has just introduced their portal and it's pretty comprehensive. Nothing quite like learning that some people use AIM instead of MSN messenger, or that there really may be a need for supporting 4 monitors ( Cyrus Complains ) However, it's really a great sign that MS is serious about supporting the blogging community which seems to have um, exploded in size in the past year. Blogs and RSS come to Microsoft.com

Programmers vs. Developers vs. Architects

I received an email this morning from Brandon Savage 's newsletter. Brandon's a PHP guru (works at Mozilla) but his newsletter and books have some great overall perspectives for developers of all languages. However, this last one (What's the difference between developers and architects?) kind of rubs me the wrong way. Either that, or I've just missed the natural inflation of job descriptions. (maybe, it's like the change in terminology between Garbage man and Waste Engineer or Secretary and Office Administrator) So maybe it's just me - but I think there's still a big difference between Programmer, Developer and then of course, architect. The key thing here is that every role has a different perspective and every one of those perspectives has value. The original MSF create roles like Product Manager, Program Manager, Developer, Tester, etc - so every concept may pigeon hole people into different roles. But the statements Brandon makes are often distinction

FoxInCloud Stats

FoxInCloud sent this link a while back about their statistics regarding visits to their site: http://foxincloud.com/blog/2017/12/27/VFP-community-lessons-from-foxincloud-site.html What's interesting here is the breakdown of people. Yes, I think it's understandable that the Fox community is getting older. Another factor is the growth of the mobile and web environments taking over development. These environments really do push people towards the newer non-SQL or free SQL/hosted environments but more towards hosted storage options like Amazon and Google. A tool like FoxInCloud that helps MOVE existing applications to the cloud inherently competes with those environments. But FoxInCloud also allows developers to extend their application further by giving them a starting point using Javascript and the basic CSS (such as Bootstrap). If you're not rebuilding your application from scratch, it's certainly a great step forward. FoxPro VFP