Recovery after Run

[Scott24x7]

Hi All,
My application has encountered a really odd behaviour in the last 2 days. In the areas I would expect to effect such a thing, I've made no change.
Here's the behavior:

While in Development Mode in VFP 9, I build the application with "Run After Build" checked (though that doesn't specifically matter if I don't tick that box and run manual, the result is the same).

So I do something (anything) in the application, and exit it normally (usually just testing something I just made).
I go back to MODIFY PROJECt, double-click a form, or make whatever changes to menu or reports.

Now, I go back to "Build" afterward, and now when I try to "build" after exiting the program under normal conditions (i.e. everything closed out fine, the way it has for decades), and I get the following message when it tries to do the build:

Title of message box reads: Microsoft Visual FoxPro
It has a yellow "Attention" sign

Message Text: Object file t:\development\...\application.exe is in use and cannot be removed from memory.

I tried CLOSE ALL, CLEAR ALL, CLEAR (issued one after the other in that order), and if I try to build after that I still get the same error.
Any idea what this could be? In all the years I've done Fox dev, I've never seen this issue.
In order to continue, I have to EXIT VFP IDE and then restart it, and then I can build again. Really annoying.


Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."

 

[Mike Lewis]

Scott,

Could it be that you are actually running a program while you are trying to do the build?

Before starting the build, take a look at the Program menu. If either the Cancel or Resume options are active (or both), then that suggests that a program is running (and possibly suspended). If so, cancel the program and try again.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Mike Lewis]

Another possibility:

Have you accidentally included the EXE file (the one you are trying to re-build) in the project? I'm not sure if that would cause this particular error, but it is almost certain to muck up the build in some way.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Scott24x7]

Hi Mike,
Neither Cancel or Resume are enabled on the Program Menu. The .exe is not included anywhere in the project. Also, in the Windows "Task Manager" there is no visible occurrence of the App.exe anywhere in it either. Totally vexed.


Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."

 

[Olaf Doschke]

Look into task manager. Your EXE is still there? Well, then you only think you exit your EXE. Notice: Run after build runs the EXE, not our main.prg within the IDE.

Why run the EXE at all? You can debug without first building the EXE and almost always get back to normal with CLEAR ALL, if your code crashes somehow in your debug session, you can only use SET and SET STEP ON and SUSPEND and other code at design time, within your EXE your debugging capabilities are near none.

Running the EXE may be the last test step, but you could only debug your EXE if you don't run it but DO main IN your.exe, so the IDE is the host process. On the other side that means you debug the source code embedded within the EXE, you only have slightly other conditions in that case, as the IDE still has all files at hand via SET PATH etc, which your end users might not get, so the best test process for the EXE is to run it on a PC without VFP, eg virtual machine. That's as staging area you can also test your installation isn't missing to provide any runtime, ocx, dll, fll, or other necessary file and your setup and update process work.

I do this separately, I never use run after build.

Bye, Olaf.

 

[Scott24x7]

It's weirder than I thought...
Testing with it a bit further this is strange behavior.
But Olaf, to your point, Run after Build, or build and then execute DO AppName from the command window are the same thing. (It runs the .exe).
I do this because I found a long time ago, I would test things in the IDE, and then when running the .EXE I got a different behavior. That was frustrating, so I went to this method, which has never been a problem until the last 2 days. Obviously something has changed, but I can't tell what. None of the things I've been doing in code should make any difference, as I'm just dealing with objects in forms.

So, here is how it got weirder:

I Run after Build:
My splash screen runs, I dismiss it.
My Login Window Appears, I dismiss it.
I select File, Exit from my topline, and return to the IDE.
I open the form (as a developer). Make some change (even just move object one pixel left, then back right so it thinks something has "changed".
Save it.
Click Build (with Build after run still on).
It builds, runs no problem.

Now, this time, I dismiss the splash screen.
I log in.
After login, Same steps as above, and all is fine.

3rd test,
Splash, login
From Main form, select configuration table from the Configuration Menu.
Closet the form.
Open the Project, Open a form, make a change save it.
Click build - runs and builds fine.

4th test,
Dismiss the splash, complete the login.
From Main Menu dropdown, select the main "Meat" of the application form "Data Centers"
Close the form.
Exit the application.
Open the project.
Open the form, change, save.
Click Build -> Bang... the message about the .EXE being open.
SO... it is ONLY when I run this form and then exit, and try to open the project.
Really really odd.


Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."

 

[foxwizard]

Scott,

I remember that error in one of my applications. I'm not sure if there is some similarity but in my case, during build it did not throw any errors and a new exe was always created. However, I realized that there was a problem in the registry of my ActiveX. I had an activeX on one of my forms and during build it couldn't find the ActiveX file and the registry failed although a new exe was created. And when I ran the exe, that same error of yours showed up. The object in the error tells you something and it is referring to one of your objects in your exe and not the exe itself.

 

[Olaf Doschke]

You're right, but the thing I do for debugging is not DO my.EXE nor DO main in my.EXE I simply do main.prg from the IDE project manager.

Anyway, you most likely have to do with something starting up the EXE for real, eg an ole class you have in your EXE. The compiler can't build a new EXE version, while the old one is in use. I avoid that by never using the EXE at all within the IDE.

Bye, Olaf.

 

[Mike Lewis]

I found a long time ago, I would test things in the IDE, and then when running the .EXE I got a different behavior.

Then that's the problem you should be tackling.

I agree with Olaf on this point. During development, don't test your program by running the EXE from within the IDE. Run the main PRG instead. If there are differences in behaviour, then find out why and fix them.

The chances are that those differences are caused by not having a "clean slate" when you run the PRG. When you run an EXE, you can be sure that everything is starting from zero: no tables in use, no variables declared, etc. You need to ensure the same in the PRG. At the very least, you should start the PRG with CLOSE ALL / CLEAR ALL / RELEASE ALL; do all the SET commands explicitly; make sure the default directory and the path are correctly set; re-declare any needed API calls; and so on.

I'm not saying this will solve your original problem, but it might well avoid it happening again. It will also save a lot of time, as you won't have to keep doing a build every time you fix an error. And it should make debugging a bit easier too.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Scott24x7]

That is interesting.
But I don't understand at all why it has suddenly become a problem. I've made over 5,000 builds of this project, and it was never an issue.
You do note the one "unique" thing about that form though. It has a simple ole object (just one) that sits on it that is the connector to interface with the web. (So when we launch web searches from within the application, it will work... we really don't use it for anything else, but it is really nice to click a "Find it on Google Maps" icon we have where any record with an address will launch the browser window and show the location in Google Maps. :/

I tried what you suggested Olaf, with running the main prg from the command window. But I think I have some sequences that don't work right that way which is also why I used a build version to test in (as opposed to the ! to run a window local). For our simple forms, like a configuration screen, they are fine, but for the more complex ones, that doesn't work out.
I'll see if I can work out how/why that doesn't work right, and give it another try.

I think I know what it is.



Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."

 

[Olaf Doschke]

Well, I can't tell you the details, but normally run after build as I now tested it, will not run a new process and your EXE is only the source of the single files it contains do your.exe does not list your.exe in the details (processes) tab of task manager. On the other side the build error you got explicitly states your EXE runs as process and therefore can't be replaced by the build process. You must have started the EXE in any way other then run after build only for this to happen. Something like that.

Bye, Olaf.

 

[Scott24x7]

Olaf,
That's seriously not what is happening.
I think foxwizard is onto something with this OLE object.

But I tried to just run from "STARTUP.PRG", it seems it's more complicated than that.
The first one I overcame, I moved a procedure from my COMMON.PRG (which gets set in the 3rd line of the startup.prg now with SET PROCEDURE TO COMMON.PRG).
But then I hit another issue.
I am using a full version of EZTwain, which needs a set high in the application. So that line:

*
TWAIN_UniversalLicense(<MyID>, <myKey>) 
*
* Just before this:
*
IF NOT glQUITAPP
	DO MAINMENU.MPR
	DO MENUINFO
	DO FORM MAIN
	DO FORM SPLASH
	DO FORM LOGIN
	READ EVENTS
ENDIF

Which is of course where my READ EVENTS management takes over. (Note those 8 lines have been the same since 1991 when I was running FPD2).



Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."

 

[Scott24x7]

Ah, it's worse.
It seems that the SET PROCEDURE TO COMMON.PRG is ineffective as well. It tries to make another call:
DO SYSINIT IN COMMON

Just before the TWAIN call, so it's actually not getting to that point. So if the COMMON.PRG isn't available, then the system isn't going to start by DO STARTUP.PRG or "Run" Startup.PRG from the Project...

Seems like it needs a whole re architect if that's going to work, and I really am not sure how to go about that. This has been how I've started FP projects for 25 years.

Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."

 

[Olaf Doschke]

I have too little insight into your dependencies, but obviously for DO to find procedures and functions SET PROCEDURE has to be one of the first. Before that, I typically put CD to a path making relative paths correct and use SYS(16) as one basis for CD into that path, if you don't CD into some folder before DO main.prg Yes, running within the IDE that way is more sensitive to pathing errors you never detected DO-ing the EXE. I'm not sure, but it seems also that mode is sufficient files are found within the EXE while it is not sufficient, when you just DO main.prg. I see it as an extra test for your correct architecture, so you might be right in that you need to reconstruct some things so you can start off.

Bye, Olaf.

 

[Scott24x7]

Olaf,
Yeah, that's what I'm doing... Sorry for dripping the code in, I thought this would be simpler. The contents of "STARTUP.PRG" is here:

SET TALK OFF

DO CLEANSTART IN COMMON

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
*
* 	Setup Procedure and Help file for DnD system.
*
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

SET PROCEDURE TO PRGS\COMMON

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
*
*	Set variables for exiting application, and for security clearances.
*
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

PUBLIC glQUITAPP, glQUITOPT, glUSERID, glAXSLEVEL, glMENUOFF, glTipState

IF NOT USED('STARTUP')
	SELECT 0
	USE DBFS\STARTUP
	REPLACE STARTUP.LOCALDRV WITH '"'+CURDIR()+'"'
	REPLACE STARTUP.SYSPATH WITH '"'+CURDIR()+'"'
	REPLACE STARTUP.SYSDEFA WITH '"'+CURDIR()+'"'
	REPLACE STARTUP.DATADRV1 WITH '"'+CURDIR()+'DBFS\"'
	REPLACE STARTUP.DATADRV2 WITH '"'+CURDIR()+'DBFS\"'
	REPLACE STARTUP.UTILDRV WITH '"'+CURDIR()+'"'
ENDIF
glTipState = .T.
SELECT STARTUP
USE
*
gcUserID = ''
gcUserName = ''
gnAccessLevel = 0
glMenuOff = .F.

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
*
*	Do one time setup for application.
*
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

DO SYSINIT IN COMMON
*
IF WEXIST('PROPERTIES')
	DEACTIVATE WINDOW PROPERTIES
ENDIF
*
ON SHUTDOWN DO CloseApp IN COMMON.PRG
*
SET TALK OFF
*
TWAIN_UniversalLicense("myidstring", -mylicsencstring)  && changed to protect my license, but shouldn't matter that's the format
*
IF NOT glQUITAPP
	DO MAINMENU.MPR
	DO MENUINFO
	DO FORM MAIN
	DO FORM SPLASH
	DO FORM LOGIN
	READ EVENTS
ENDIF
*
CLEAR ALL

So there is some setup, then these 8 lines are your "static main void" equivalent, and then the CLEAR ALL only executes after the READ EVENTS is resolved, so when you come back to dev environment, you don't have any klingons.

Any reason this wouldn't work as a DO STARTUP.PRG?


Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."

 

[Olaf Doschke]

You rely on default path being your project home. And I would put the SET PROCEDURE first, then you also don't need IN COMMON, just call CLEANSTART()

Bye, Olaf.

 

[foxwizard]

Scott,

Just giving you another option, why don't you make a copy of your application on another folder and use that copy to play with your ole object. You can remove that ole object temporarily then compile. Of course, you have to comment out those codes that makes use of that ole object, otherwise you'll get errors and possibly you won't be able to compile it. If that error do not show up again after removing the ole object then the problem really lies on the ole object. Next step is to try to figure out the cause and fix it. Later on, you can put back the object again after doing the fixes.

Hope this helps.

 

[Scott24x7]

Foxwizard,
You know that was a very crafty suggestion. And after removing the OLE object (didn't need to comment the other bits out because they are all only related to drag and drop from the internet into the application, so none of them fired), I would have bet money that it would show as the problem, as it is one thing that ONLY that form has on it... but, even after removing it, and running that form, the same error persists! So, it IS related to this form (I can launch/run any other form in the application without this result), but it's NOT related to the OLE object, as I had suspected. Now it's even more annoying.


Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."

 

[Scott24x7]

Foxwizard,
I took this further extreme to see if I can 100% pin it to this form. I actually removed the entire pageframe from the form, and deleted a couple of buttons that reference it. It's basically a blank form with some navigation button set on it, and some open/close/max window controls. After run, added a label, and click build, and it ran without the memory error...

I may restore it now, and remove the pages from the frame one at a time, if I can get that to compile still, and see if I can find the page that the issue is on (so long as it's not the first page...)


Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."

 

[Scott24x7]

So this is just about the WEIRDEST thing ever...
I have found the issue, and I can replicate it on THAT form, but not on another one.

I have two text boxes that I use for searching (one for companies, one for contacts). I, sometime yesterday, decided to move them to another location on the form (just above their grids instead of at the bottom corner). But then they looked kind "lonely", and unobvious.

So, I added an image box at the end of each text box, and put a magnifying glass .png file in as the image (24 x 24). But the magnifying glass pointed down to the bottom left corner of the image and I thought it would be better to have them at least pointing up. So I used the "Rotate" property on the two image boxes....

WOW

When I turn rotate off, then the error on rebuild doesn't occur.
I turn rotate 90 degrees back on, and wham, same thing.
No idea what is actually going on. There is nothing special about these, just two images rotated 90 degrees... had nothing to do with OLE objects.

I found it by Removing large chunks of controls from the page at a time until it stopped, and then narrowed it down to there, plus I realized I had placed those two objects yesterday, but hadn't equated the problem starting at that moment. (Probably didn't notice it for a while). But this one is crazy. I tried to replicate it on another form with a different .png, and only 1 and it didn't have the same problem, but now I'm going to copy those two images over to another form, and rotate them, and see if I get the same problem.
Very odd...

Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."