when clicking on the exe file(vfp 9.0 spk2) it just blink and disapears

[land_fla]

Hi again,
What can cause this ?
when clicking on the exe file i just compiled( under vfp 9.0 spk2) it just blink and disapears
Thanks in advance

Of course if you need more detail, let me know, i just added a config file, where i have there, screen = off

 

[land_fla]

ok i will

thanks

 

[Olaf Doschke]

Once you're finished with starting the newly compiled EXE the easiest way to look at the log file is by loading it as data.
There is a tool called coverage profiler, but this won't help you simply look at what executed row by row.

Create Cursor curCoverage (bExecTime B, cClass C(128), cMethod C(128), iLine I, cFile C(254), iStacklevel I) 
Set Point To '.' 
Append From (ADDBS(GETENV("TEMP"))+"yourapp.log") Type CSV

Now browse and look at the end few rows. I expect something reported from the form, hitting Read Events and then something causes either a premature Clear Events or Quit, or an error, or something even I don't expected. You'll not see code but filename/class/method and line number. To know what code line that is open the same file/class/method and go to that line number, obviously. Having two displays helps in this situation.

Bye, Olaf.

 

[land_fla]

I fix the problem, by just adding in the active form "read events" and in the Load event "_screen.visible = .f."
That fix my problem
But i will have this in mind as what you told me it is a good thing for testing on the exe in case something else fails
Thanks

 

[Olaf Doschke]

You can't have a read events in a form method. That keeps this method on the call stack all time, the method never ends.
Read Events belongs after DO FORM or oForm.Show(), nowhere else.

Another simple reason your EXE still doesn't work: Do you really have this PRG code set as your main pjx file? Perhaps your form is the main file and starting the EXE merely starts the mainform and nothing else. You need to have the main.prg set as the main file, it has to appear bold in the list of PRGs in the project manager.

in the IDE you can start your main.prg, so it works there, but it's not started when you start your EXE, as it's not the main file, that would explain a lot.

Bye, Olaf.

 

[Mike Lewis]

Read Events belongs after DO FORM or oForm.Show(), nowhere else.

Just to be exact, it can also appear after a command that launches a menu or a toolbar (admittedly that won't apply in this case).

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[dbMark]

Is it working now or are you still trying the suggestions? Do you have all the main support files where the EXE can find them? The EXE is standalone but it also needs the VFP support files.

Minimum required DLLs accessible there with EXE or in the PATH:

vfp9r.dll
vfp9t.dll
vfp9renu.dll
msvcr71.dll (should be 02/21/2003 or newer; may be elsewhere on the computer)
gdiplus.dll (must be 08/04/2004 or newer; may be elsewhere on the computer)

 

[Ernesto_Paez]

oK,
It is working now
Yes i have all those file in the same folder with the exe file.

The problem was that i had screen = off in the config file and also showwindow = 0 in the form property, so i changed to showwindow =2 and READ EVENT it is in the main.prg after DO FORM.

and yes my main.prg it is in the project as the main file as bold, so problem is solved and i want to thanks everyone of you and each of you for your fast response.

I never created a Method in the form, and for hence did not put the Read event in a Method, i said i added in the form Activate property , the "Read Event"
Thanks everyone

 

[Olaf Doschke]

I never created a Method in the form, and for hence did not put the Read event in a Method, i said i added in the form Activate property , the "Read Event"

Activate is not a property of the form, It is an event, strictly speaking, and not stictly speaking methods and events of a form, including the native ones were meant by me. Activate happens multiple times and will then only execute up to the READ EVENTS line and when you activate the form more than 127 times you'd most probably get a stack overflow error, not sure, though. READ EVENTS doesn't beloing into an form method or event, including the native methods and events.

i changed to showwindow =2 and READ EVENT it is in the main.prg after DO FORM

That's fine.

As I stated several times already, I thought you had ShowWindow=2 from the beginning, as you saw something blinking. Even if you didn't, that's a major ingredient I thereby already pointed to. You wouldn't even see anything blinking with a) SCREEN=OFF and b) no ShowWindow=2 (as top level) form, a ShowWindow=0 form just runs invisible, as it's in _SCREEN and the _SCREEN is invisible. So that's weird, now. I think you have to embed the config.fpw file, i.e. include it into the compilation, to get the effect the _Screen never is visible. Just putting config.fpw side to side to an EXE makes VFP use it, too, but delayed, perhaps. That could explain the blink. But of course you don't see anything, if your main for is in screen and the screen is hidden.

You need all these ingredients for a SDI application to work: SCREEN=OFF, Top Level Form, READ EVENTS/CLEAR EVENTS. Optionally RESOURCE=OFF is a good way to prevent VFP to fail on creating the foxuser.dbf in the write protected Program Files directory or since Vista redirect this to the user profile. And the config.fpw has to be included in the EXE. An ALLOWEXTERNAL=ON allows you to later add another config.fpw from outside and apply it with the -C command line switch any VFP built EXE supports. These ingredients are all explained in the How To FAQ I already pointed to and are all demonstrated in it.

Bye, Olaf.

 

[Olaf Doschke]

Just to be exact, it can also appear after a command that launches a menu or a toolbar

The most important thing is, it is executed when your application is in the state waiting for the user to use it, all preparations and initialisations are done, you don't have any modal state via a modal form and you obviously don't want to let the EXE quit.

Longer ago I also stated I found the READE EVENTS in the VFP wizard classes, precisely in the readevents method of the _application class of the _framewk.vcx in HOME()+"wizards"

THIS.ClearLastError()
IF THIS.lReadEvents
   READ EVENTS
ENDIF

You can do this, it's not technically forbidden, it even makes sense in this way, but it's off topic to discuss the workings of this application class. For simple applications you should simply have the READ EVENTS in the main.prg code after starting a non modal form. You can use a modal form without READ EVENTS, that would then run after you close the form and keep the application.EXE in task maanger, though it then should finish. But since you can only have a modal form within a top level form, your app then either needs to use the _SCREEN, or have a two form design with a top level nonmodal form and a modal form inside that, bot started at startup.

Bye, Olaf.

 

[Olaf Doschke]

Just curious, what really happens, if you put a READ EVENTS into the Activate event of a form: It works kind of, but the Activate Event doesn't happen anymore. So you also don't get a stack overflow, as I thought, but you can't write any activate behavior of your form, it never reactivates the form. Base behavior still runs, eg the form UI changes as with normal transition from inactivated to activated state.

It's nevertheless a non ideal location.

Besides Activate never being triggered again, as it still and always runs, Destroy also isn't triggered, when you click the close button, the form doesn't release, as it still runs and never finishes its first and only run of the Activate code, so if you put CLEAR EVENTS in Destroy you never get out there. You would need to put it in a quit menu item or into QueryUnload, but then still have the quirk your Activate code doesn't rerun with every form activation.

Bye, Olaf.

 

[Ernesto_Paez]

Will look into it on tuesday, thanks so much for all those clarifications and at the same time the explanation of things i did not know
Again have a great happy new year to all of you.
Ernesto