How to Hide Compilation Progress Window in Run-Time? 1

[TomasDill]

Question is not easy and it is very tricky, please, read carefully (I will try to describe problem with my knowledge of English). 4 well experiensed VFP programmers tried to find a solution for this problem and have no success.
We have very dynamic application that runs some programs on When event or validation of form fields. These programs are subject of often changes (say, they contain functions with SQL-SELECT queries). We need to set this PRG file as procedure file.
PROBLEM:
In RUN-TIME, SET PROCEDURE command do not set external procedure .PRG file when it is not pre-compiled to .FXP file. Looks like VFP try to find .FXP file by .PRG file name in the project compiled into EXE file, not on the disk. So it shows message like "File 'MyProc.PRG' does not exists", without path. Path specified exactly, either macro ('&') or expression/variable do not work in this command.
Ok, we use COMPILE command to pre-compile PRG file. However, it always shows compilation progress window. It blinks for the moment, that may not be a problem. The problem is that we need to lock screen from refreshes (thisform.lockscreen = .T.) during some process. When we compile something during that process, compilation window shown and than left on the screen until LockScreen will not be set to .F., showing garbage to users. We tried all combinations of all settings in VFP and did not found a way to hide it by VFP commands.
QUESTION:
How to hide compilation window of COMPILE command in run-time? Maybe someone know some tricks using old VFP commands that work with windows?
NOTE: Please, do not propose solution with running of VFP Automation Server object and compile PRG file using 'DoCmd'. It is too slow to load this object each time when compiling, and too memory-consuming to keep it running from start of application just to hide compilation window.
NOTE2: VFP does not show compilation windows when program is very small. Sure, whe I use SET PROCEDURE command in design-time, little program compiled without any messages. However, COMPILE command in run-time shows compilation progress window ALWAYS despite size of PRG file.
NOTE3: Solution with hiding of main VFP window and make another window at desktop does not works too. VFP shows compilation progress at desktop!

 

[jonscott8]

AFAIK, there isn't a way to suppress the compiling dialog that is presented with the COMPILE command. The VFP development team forgot to add a NOSHOW clause to the commands that result in a user interface, ie. COMPILE, REPORT FORM, etc.

A request has been added to the VFP 7 wishlist to add a "NOSHOW" clause to these commands and is supposed to be addressed in the next release.

It is annoying because it prevents the use of these commands in In-Process automation servers and Out-of-Process servers with SYS(2335,0).

If I understand you correctly, you are copying the .PRG file over the old .PRG file, and when attempting to SET PROCEDURE TO your new file, you get the error. And this is why you are attempting to programmatically compile the .PRG file. Correct?

Is there a reason you can't just manually compile the .PRG file, copy the .FXP file over the old one, and then the SET PROCEDURE TO should work?? [sig]<p>Jon Hawkins<br><a href=mailto: jonscott8@yahoo.com> jonscott8@yahoo.com</a><br><a href= > </a><br>Carpe Diem! - Seize the Day![/sig]

 

[TomasDill]

Yes, because PRG file built in run-time. Its some sort of application that changes self accordingly to data, in other words. Really, it is used for SQL SELECTs that are dynamically built by users in our query builder. It works perfect, except annoying compilation progress window [sig]<p>Volodymyr Grynchyshyn<br><a href=mailto:vgryn@softserve.lviv.ua>vgryn@softserve.lviv.ua</a><br>[/sig]

 

[csr]

Here is a thought ...

Why not create a program ... separate from the application that uses the compiled program you are speaking of ... that does nothing but checks the date and time stamps on the programs and if it finds a pair of PRG/FXP files with different time stamps ... compile it. You may have to allow some variation in the time stamps as normal but you get the idea. Then the compiling could be taking place on some other little used terminal while others are going merrily on their way at other terminals.

Well, just a thought ...

[sig]<p>Don<br><a href=mailto:dond@csrinc.com>dond@csrinc.com</a><br><a href= > </a><br> [/sig]

 

[TomasDill]

This is nice idea, but not good too in our case. We generate PRG files that have unique names. 1 application can run many custom queries. In addition, user can run 2 application instances at the same time. Finally, we have package of applications, not just a single EXE. Some af applications in this package generate such PRG files. They also should not caus conflicts between each other.
Than, imagine - we need to communicate with compiling aplication to send information about PRG file names, this require additional programming. Compiling application - another instance of VFP application, that also takes memory, like a COM object (VFP Automation Server). I see no differense with VFP COM object... [sig]<p>Vlad Grynchyshyn<br><a href=mailto:vgryn@softserve.lviv.ua>vgryn@softserve.lviv.ua</a><br>[/sig]

 

[csr]

Well, my idea may not be suitable for your situation.
However, the part about having to communicate with the compiling program may not be entirely true. Just have the compiling program continue to look for PRG files that either (1) have no FXP file or (2) for which the FXP file has a date/time stamp older than the date/time stamp on the PRG file. Anything it finds ... compile it.

In your main application, have all statements which are about to execute one of these remote compiled programs ... always check for date/time stamp on PRG and FXP prior to executing ... if FXP is not later ... wait until it is ... then execute it.

Again ... just an idea.

[sig]<p>Don<br><a href=mailto:dond@csrinc.com>dond@csrinc.com</a><br><a href= > </a><br> [/sig]

 

[jonscott8]

Vlad,

I came across this thread while searching for another and since I now know the answer, I thought I'd post it in case you never found the solution or if anyone else comes lookin for it.

A simple implementation:

LockWindowUpdate(.T.)
COMPILE MySource.prg
LockWindowUpdate(.F.)

FUNCTION LockWindowUpdate()
lparameters tlLock

local lnHWnd

declare integer LockWindowUpdate in Win32API integer nHandle
if tlLock
declare integer GetDesktopWindow in Win32API
lnHWnd = GetDesktopWindow()
else
lnHWnd = 0
endif
LockWindowUpdate(lnHWnd)
return

NOTES: LockWindowUpdate only suppress the drawing in the specified window. Thus, the compile dialog is still being called; however, it is transparent to the user because drawing is suppressed. Therefore, you still cant use this implementation in In-Process DLLs because the calling of the UI would still throw an error.

In VFP7, the COMPILE command will adhere to the SET NOTIFY setting and therefore will be suppressed entirely if SET NOTIFY is OFF, making its use in In-Process DLLs feasible. At this point, I'm unaware if the printing dialog presented by the REPORT command will respect SET NOTIFY. Jon Hawkins

The World Is Headed For Mutiny,
When All We Want Is Unity. - Creed

 

[TomasDill]

Hi, Jon!

Nice idea.

We already solved this problem by another inetersting way that might be useful also in many other cases.
The solution is based on the Windows hooks. We made a simple FLL file using C++ that defines windows hook. Than in the hook procedure we prevent ANY window opening (creating) when switched on. Thus we switch on this before compiling, compile (command window don't shown because hook procedure prohibit that) and than disable this mode to allow other windows being opened.

Above approach may be used in many other cases, for example, to suppress annoying open dialog box when alias not found in many commands (I did not relly tried this, but I suppose it should work in this case). If you want, I may contact with C++ programmer in our team that made such FLL file.

As about COM objects, you can easy check if you;re in COM object using following function:
sys(2335)
It returns empty string in all VFP applications but COM object. In COM object it returns usually '0', in EXE COM object it might return '1' if you set it by this function.
So its not a problem



Vlad Grynchyshyn
vgryn@softserve.lviv.ua

http://www.softserve.lviv.ua

The professional level of programmer could be determined by level of stupidity of his/her bugs

 

[jonscott8]

Vlad,

Glad to hear you devised a work-around. Sounds like our implementations achieve the same result (suppress display, not the actual call to the UI) using distinctly different methods.

IRT suppressing the other dialogs from the user, I agree mostly. IMO, the practicality depends on the command, which I have found to be odd. I would advocate against attempting to suppress a dialog that presents as modal, because it would probably appear to hang the PC from the user's perspective. At least, that is the case under my implementation, I can't speak for yours.

As an example of what I'm speaking of, try this. Paste the following into a main prg and build an executable.(Include the LockWindowUpdate function I posted above in your main prg).

=MESSAGEBOX('Before Compile',0,'')
LockWindowUpdate(.T.)
SELECT * FROM MyTable

&& MyTable does not exist

LockWindowUpdate(.F.)
=MESSAGEBOX('After Compile',0,'')

After running the exe and clicking the first message box, you'll notice it appears the PC has froze. It doesnt respond to any keyboard or mouse activity. Press ALT+TAB and switch back to the application. You'll notice that the open dialog has reappeared.

AFA testing if you're in a COM object, why not use the StartMode property or the application object?

Application.StartMode = 2 && Out-of-Process
Application.StartMode = 3 && In-Process Jon Hawkins

The World Is Headed For Mutiny,
When All We Want Is Unity. - Creed

 

[TomasDill]

Hi!

I guess method wityh windows hooks should work for preventing dialog box appearing because it does prevent window opening at all, thus wich window will be in the modal state? ;-)




Vlad Grynchyshyn
vgryn@softserve.lviv.ua

http://www.softserve.lviv.ua

The professional level of programmer could be determined by level of stupidity of his/her bugs