Runtimes/EXE fails to run

[k2a]

When starting the app.exe it fails to run. It seems that the app gets killed immediately because I do not see it in the Windows task manager.

I created many runtimes and exe before the very same way without any problems. But after making a bunch of changes to the new app version it now fails.

The difference between the previous working app version and the new one are these: performed many changes at some forms, also made changes in the menu and data tables. The new app version runs fine when starting it from the main.prg on the development system. There are no errors when the exe and setup.exe files are being generated. I use Inno to create the setup.exe file. The runtimes and the exe are installed in the same folder.

The runtimes/exe folder is installed on different systems but the database is located on a server system. When any changes are made on the database the data on server are also replaced along with the new app version.

What could I do to find out the reason why the new version fails?
Any help will be appreciated.

Klaus

 

[EzLogic]

Silly question, but, important one.

do you have "Read events"?

Ali Koumaiha
TeknoSoft Inc.
Michigan

 

[Mike Lewis]

Klaus,

To expand on Ali's response, this page might be useful: faq184-4232

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[GriffMG]

You don't HAVE to have a READ EVENTS - I don't use it at all.

In this case I would suspect a mismatch/missing runtime file.

Check your app has been compiled in the same version and SP as
your runtimes are for, and double check they are all there and
not spoilt.

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

 

[GriffMG]

To run without READ EVENTS I *think* the trick is to make your opening form MODAL.

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

 

[Mike Lewis]

Griff,

You're right about the form being modal.

But, reading Klaus's post in detail, I don't think your're right about missing runtime files. I would have thought that would lead to an error message, rather than the program silently exiting.

I think it's likely that READ EVENTS is indeed the issue, although we must wait for Klaus to come back to comfirm that or otherwise.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[GriffMG]

Hi Mike,

You might be right, but you don't *always* get an error message.

I'm thinking he has updated to SP2 (for example) and thus his
dev. machine works fine, but his install package is still picking
up the older runtimes... we will have to wait and see.

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

 

[Mike Lewis]

Fair enough, Griff. As you say, let's wait and see.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Olaf Doschke]

I'm waiting, too.

While waiting about the READ EVENTS / Modal or Runtime issue..

A thing you could do in any case is add in some Messageboxes. That's perhaps the most inelegant way, but you'll see how for into start.prg you go.

And what you can also do for a testing phase is
SET COVERAGE TO d:\temp\app.log

That will log all lines of code running in a machine readable log format you can read in via Coverage Profiler. Again, as the app vanishes a small log is to be expected, but you see where it exits.

Bye, Olaf.

 

[Dan Freeman]

You don't need a READ EVENTS *IF* (there's that important word!) the application launches a form. If the application simply installs a menu and waits for a user to do something, READ EVENTS is an absolute must.

Another thing that could cause this problem is having the wrong file set as "Main" in the project, but you'd sort of expect to see an er5ror message if you're running code out of turn.

 

[Olaf Doschke]

ANDIF the form isn't modal, you also need to READ EVENTS. But we also already had that.

ELSEIF the form is is ShowWindow=2 (as top level form), then you can set its WindowType = 1 (modal) as often and as hard as you like, but it won't get modal, and again you need READ EVENTS.

BUTIF READ EVENTS was missing, this would most probably already have shown and been solved in earlier application versions. Klaus said he had no problems in earlier versions.

Bye, Olaf.

 

[k2a]

Thank you all of you for your quick response, I’m really overwhelmed.

The behavior of my new setup.exe is very mysterious. I compared the files the new setup creates with one of the previous version which runs correctly. The runtime files are in magnitude and quantity equal the only difference is the app.exe which is a few bytes bigger. That makes sense because I added new features to it.

My app uses an READ EVENTS it is located in exapp.do method, so I added an additional command to it
DO menus\mahnwesen.mpr, that what Mike’s tip suggested.

Than I added to my main.prg the command SET COVERAGE TO c:\temp\app.log that what Olaf advised me to do. I generated two log-files one when starting the app from the main.prg and the other one received from my failing new app.

The files are different the failing one is the smallest and it stops when it runs the exapp.do method. This is really strange because I did not make any changes to that object.

But what cause kills my app?

Klaus

 

[Olaf Doschke]

Okay, so the coverage log last line is the call to exapp.do? And that fails? Is it perhaps, that the exapp instance has failed to init and therefor any call to it fails? Could you post the start.prg and what last lines were executed?

Is the class or classlib perhaps broken? Can you still edit it and have code in do?

Or does the coverage log stop on read events? That would be normal, of course, but then the question is, why nothing shows up. config.fpw with SCREEN=OFF?

Bye, Olaf.

 

[k2a]

Hi Olaf,
It seems that coverage log stop on read events because there is only this command code in do.
Below are the last lines from the log-file that failed:
0.000023,,,152,mahnwesen.mpx,3
,exapp,exapp.do,7,c:\program files\bfs-mahnwesen\libs\exbase.vct,2
,,on shutdown,,,3
0.000040,,appquit,59,c:\program files\bfs-mahnwesen\mahnwesen.exe,4
,,appquit,60,c:\program files\bfs-mahnwesen\mahnwesen.exe,4

Oops, i never attached a file to a thread, let me know whether you received my main.prg or not.

Klaus

 

[Olaf Doschke]

You can't attach a file on your drive. Simply put in some code lines, the essential ones. And if you want it pretty, select it and click on the code toolbar button (three left of the preview button).

What springs to my eye is there is "on shutdown" happening. What is your on("shutdown") setting?

Bye, Olaf.

 

[k2a]

Sorry Olaf, but still didn’t catch how to attach files, blame on me.

The shutdown setting in my main.prg is this:

ON SHUTDOWN DO AppQuit
FUNCTION AppQuit
CLEAR EVENTS
ON SHUTDOWN
ENDFUNC

Just created some more log files. One file is from my previous good version and the other one from the new failing version. However, I reversed a couple of things, so I use the main.prg from the previous good version and also reversed some changes made on a form. That did not fix it.

Also checked the exapp class from both versions and there is no difference. I also keep a changing list to see what has been changed from version to version. Unfortunately that list does not go too much into the details. Reversing all the changes step by step would be awful tedious job.

Any other suggestion?

Klaus

 

[Olaf Doschke]

I still think about reasons, why the on shutdown is logged right after READ EVENTS. If I got you right, line 2 is READ EVENTS Seems like right after you go into read events something happens causing the shutdown. What's ON('ERROR')? You don't do ON ERROR QUIT, do you?

You could write another log file via SET EVENTTRACKING. Set the eventlist to all events via the debugger, that's much easier than by SET EVENTLIST. For the runtime logging, you have to write a SET EVENTLIST TO statement. Use _cliptext=SET('EVENTLIST') to get the list of events you set in the debugger (in Tools, Event Tracking).

Look, if you got some CANCEL or QUIT or CLEAR EVENTS anywhere else in your code you may have put in for testing purposes and forgot to remove. Use Code References to search the whole project.

Also try to put some lines before READ EVENTS, clearing anything from keyboard and event buffer, which may cause a premature quit directly or indirectly:

_cliptext = ''
KEYBOARD '' CLEAR
DOEVENTS FORCE
READ EVENTS

This way, no event waits for processing, when you go into READ EVENTS. If your app then still finishes, have you got anything out of the normal execution order? Is there any timer running?

Bye, Olaf.

 

[k2a]

OK, Olaf

Just tried to do what you suggested, but are not quite sure whether I did it correctly. The EVENTTRACKING log files has not been created only COVERAGE log file.

Added the following commands into my main.prg
SET COVERAGE TO c:\temp\app_v20.log
_cliptext=SET('EVENTLIST')
SET EVENTTRACKING TO c:\temp\EventTrack_v20.log

and in exapp.do methode
_cliptext = ''
KEYBOARD '' CLEAR
DOEVENTS FORCE
READ EVENTS

The last few line from app_v20.log
0.000017,,systeminfo.activate,21,c:\program files\bfs-mahnwesen\forms\systeminfo.sct,2
0.000014,,systeminfo.activate,25,c:\program files\bfs-mahnwesen\forms\systeminfo.sct,2
0.000025,,mahnwesen,42,c:\program files\bfs-mahnwesen\mahnwesen.exe,1
0.000016,,mahnwesen,44,c:\program files\bfs-mahnwesen\mahnwesen.exe,1
,,mahnwesen,45,c:\program files\bfs-mahnwesen\mahnwesen.exe,1
0.003358,exapp,exapp.do,1,c:\program files\bfs-mahnwesen\libs\exbase.vct,2
,exapp,exapp.do,6,c:\program files\bfs-mahnwesen\libs\exbase.vct,2
0.000098,,systeminfo.cmdbeenden.click,1,c:\program files\bfs-mahnwesen\forms\systeminfo.sct,3
,,on shutdown,,,3
0.000106,,appquit,58,c:\program files\bfs-mahnwesen\mahnwesen.exe,4
,,appquit,59,c:\program files\bfs-mahnwesen\mahnwesen.exe,4

I did not quite understand what you meant by >>> Set the eventlist to all events via the debugger, that's much easier than by SET EVENTLIST. <<<

Thank for your help.

Klaus

 

[Olaf Doschke]

You log already shows an interesting entry:

0.000098,,systeminfo.cmdbeenden.click,1,c:\program files\bfs-mahnwesen\forms\systeminfo.sct,3

So it seems there is a click on the exit button (beenden = end, exit, quit). That would explain, why the app does not persist, quite esily.

Do you have code in form init or activate, that calls the cmdbeenden.click? Is there a hotkey defined to trigger that button? I'd bet the line in it is either QUIT or CLEAR EVENTS, either in that systeminfo form or in it's base class.

In regard to eventlist and the debugger:
1. In VFP change to the Debugger via Menu Tools, Item Debugger
2. In the Debugger choose Event Tracking from it's Tools menu.
3. In the Event Tracking dialog move all events from left to right, confirm by clicking OK
4. instead of writing _cliptext = SET('eventlist') into start code, do that now in the command window. You wil then have the list of all events in the clip text.
5. In your start prg write SET EVENTLIST TO , then press CTRl+V to paste in the event list.

The command line you'll get will be too long, so you have to make a few SET EVENTLIST calls with ADDITIVE. You should end up with something like
SET EVENTLIST TO AfterRowColChange, AfterCloseTables, ....
SET EVENTLIST TO DragOver, DropDown, Error, ... ADDITIVE
SET EVENTLIST TO MouseEnter, MouseDown, ... ADDITIVE
...
I think I don't overlloked somethng as stupid as SET EVENTLIST TO ALL.

Now to turn on EVENTTRACKING you don't only need to specify that and SET EVENTTRACKING TO somefile, but also SET EVENTTRACKING ON as the last step. And only then you get a log file of events.

Bye, Olaf.

 

[k2a]

After modifying the main.prg compiled and build a new setup.exe there is no c:\temp\EventTrack_v20.log just a new c:\temp\app_v20.log

There are 18 SET EVENTLIST TO lines in my main.prg, parts of it look like this:
SET EVENTLIST TO BeforeCursorAttach, AfterCursorAttach, BeforeCursorDetach, AfterCursorDetach, BeforeCursorClose ADDITIVE
SET EVENTLIST TO AfterCursorClose, BeforeRecordRefresh, AfterRecordRefresh ADDITIVE
SET EVENTTRACKING TO c:\temp\EventTrack_v20.log
SET EVENTTRACKING ON
SET COVERAGE TO c:\temp\app_v20.log

By the way the line from my last log file had a line such as:
0.000098,,systeminfo.cmdbeenden.click,1,c:\program files\bfs-mahnwesen\forms\systeminfo.sct,3

This was caused by the splash screen window which was called from my main.prg and i deleted it manually.

The end of the new log looks like this:
0.000026,exapp,exapp.createtoolbar,16,c:\program files\bfs-mahnwesen\libs\exbase.vct,3
0.000038,,mahnwesen,62,c:\program files\bfs-mahnwesen\mahnwesen.exe,1
,,mahnwesen,63,c:\program files\bfs-mahnwesen\mahnwesen.exe,1
0.000046,exapp,exapp.do,1,c:\program files\bfs-mahnwesen\libs\exbase.vct,2
0.000057,exapp,exapp.do,6,c:\program files\bfs-mahnwesen\libs\exbase.vct,2
0.000025,exapp,exapp.do,7,c:\program files\bfs-mahnwesen\libs\exbase.vct,2
0.300085,exapp,exapp.do,8,c:\program files\bfs-mahnwesen\libs\exbase.vct,2
,exapp,exapp.do,9,c:\program files\bfs-mahnwesen\libs\exbase.vct,2
,,on shutdown,,,3
0.000039,,appquit,76,c:\program files\bfs-mahnwesen\mahnwesen.exe,4
,,appquit,77,c:\program files\bfs-mahnwesen\mahnwesen.exe,4

The question is now why eventtraching file c:\temp\EventTrack_v20.log created?

Klaus