VFP 9 DLL How can I hide wait windows

[pjohnston440]

Is there a way to hide VFP WAIT windows so that my VFP DLL doesn't fail when it executes a WAIT WINDOW command? I thought I saw a command a while back to disable all VFP screen output but do not remember what it is.

Thanks

 

[Mike Lewis]

I think SYS(2335, 0) is what you are looking for.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business

 

[Mike Lewis]

Alternatively:

IF NOT INLIST(_VFP.StartMode, 1, 2, 3, 5)
  WAIT WINDOW "Hello World
ENDIF

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business

 

[pjohnston440]

The SYS function was the one I was looking for. I spent some time looking for it this morning but didn't realize that was the one. I've been down the "wrap all outputs in an if-endif" road before and didn't want to do that again.

Thanks for your help.

 

[craigber]

The bigger question is, "why do you have WAIT WINDOW in a DLL?"

Craig Berntson
MCSD, Visual FoxPro MVP,

http://www.craigberntson.com/blog

 

[Olaf Doschke]

I doubt SYS(2335,0) is really what you're looking for, because it does not turn off wait windows or modal states in general, it will raise an error if such things happen while the "unattended server mode" is enabled.

So instead of a wait window not being seen, you get an error. Also, this SYS(2335) only applies to EXE and won't have any effect on your DLL anyway, because there you can't disable unattended servermode.

These excerpts of the help is what I refer to:

a) When unattended mode is enabled, a Visual FoxPro error is generated whenever a modal state occurs. Your .exe automation server can trap for these errors with an ON ERROR routine.

b) Note that SYS(2335) applies only to .exe automation servers for which the StartMode property equals 2 or 4. Unattended mode is always enabled for in-process .dll automation servers (for which the StartMode property equals 3).

In fact you better had a central message displaying method/function and would call it from anywhere instead of directly using anything modal like a messagebox or wati window. Now you really need to go through every routine eventually doing a modal state.

Bye, Olaf.

 

[Mike Lewis]

I've been down the "wrap all outputs in an if-endif" road before and didn't want to do that again.

I can understand that.

Personally, I don't use wait widnows, but I do use messageboxes a lot, which present the same problem.

As far as I possible, I use a messagebox wrapper function. So I only have one call to the native MESSAGEBOX(). This has several advantages - for example, it lets me use an application-wide title for the message without having to hard-code that title throughout the app.

If you had a similar function, it would be easy for you to incorporate your "if DLL" wrapper. But I guess it might be too late for you to do that retrospectively.

Just a thought.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business

 

[pjohnston440]

All - Thanks for your input.

craigber - We are developing a c# app but need to hit some legacy vfp code.

OlafDoschke - Nice catch. I haven't actually tried the sys(2335,0) function yet, but will just to see what happens.

MikeLewis - Looks like I'm going down that road again. The wrapper idea is a good suggestion.

Thanks,
Pete

 

[craigber]

Pete,

As part of your development efforts you should remove all UI elements from the VFP DLL.

Craig Berntson
MCSD, Visual FoxPro MVP,

http://www.craigberntson.com/blog