INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS

Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Jobs

Recovery after Run

Recovery after Run

(OP)
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."hammer

RE: Recovery after Run

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

RE: Recovery after Run

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

RE: Recovery after Run

(OP)
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."hammer

RE: Recovery after Run

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.

RE: Recovery after Run

(OP)
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."hammer

RE: Recovery after Run

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.

RE: Recovery after Run

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.

RE: Recovery after Run

Quote:

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

RE: Recovery after Run

(OP)
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."hammer

RE: Recovery after Run

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.

RE: Recovery after Run

(OP)
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:

CODE

*
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."hammer

RE: Recovery after Run

(OP)
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."hammer

RE: Recovery after Run

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.

RE: Recovery after Run

(OP)
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:

CODE

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."hammer

RE: Recovery after Run

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.

RE: Recovery after Run

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.

RE: Recovery after Run

(OP)
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."hammer

RE: Recovery after Run

(OP)
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."hammer

RE: Recovery after Run

(OP)
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."hammer

RE: Recovery after Run

(OP)
I've now replicated this problem on another (simple) form.

Can someone confirm this: Take any simple form you have. Place 2 image objects on the form, make the 24 x 24. Use as 24 x 24 png image (just for consistency). Rotate them both 90 degrees.
Compile the app, run the app. Open that form, close that form.
Go back, make any change on the form (add a label or something), close the form, click build on the project...
Do you get a message similar to this:

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

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

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

RE: Recovery after Run

(OP)
So the moral of this story...
Rotate your images in photoshop BEFORE placing them on a form, and don't use the object's "Rotate" ability.
At least not if you have 2 of the same image on screen. (I tried this with 1 image rotated, and it was fine... when I put 2 on, boom.)

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

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

RE: Recovery after Run

I have only browsed this thread briefly, but this sounds like you're missing a Clear Resources somewhere.

RE: Recovery after Run

I get "File cannot be closed because outstanding references exist" (Error 1184), when not closing the main form of my application before the next BUILD with Run After Build option checked, but that is to be expected, I guess. And that also happens without these images I added.

I don't get the error you tell. When I close the main form I don't get a build error. I don't think it is related to something as weird as just rotating an image. Have you tried with any other image not processed by Photoshop? EG PNGs Microsoft Paint generated?

Bye, Olaf.


RE: Recovery after Run

(OP)
Olaf,
I can accept there may be other factors in my environment that may be influencing this, but I have now proven repeatedly in my own environment that very strangely, 1 object rotated is not an issue, but two is.

Tore,
Sorry mate, it's not that. Because if I rotate the PNGs beforehand, and just leave the image as Rotate = 0, it all works fine.

I get that this is REALLY WEIRD. But I can replicate it, using my sub-class forms (all of them) and my sub-class image control x 2 rotated 90 degrees. I didn't try other rotations but maybe later I will.

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

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

RE: Recovery after Run

Scott,

CODE --> quote

Can someone confirm this: Take any simple form you have. Place 2 image objects on the form, make the 24 x 24. Use as 24 x 24 png image (just for consistency). Rotate them both 90 degrees.
Compile the app, run the app. Open that form, close that form.
Go back, make any change on the form (add a label or something), close the form, click build on the project...
Do you get a message similar to this:

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

no way works as advertized, no problems.

Regards,
Jockey4

RE: Recovery after Run

I still think this is due to a specialty within the PNG file done by Photoshop.

I have done what you instructed and don't have the problem.

Bye, Olaf.

RE: Recovery after Run

(OP)
Olaf,
No, it's not. I know because I didn't create this PNG and I tried it with other 32 x 32 png (and 24 x 24) size was not the issue.
It is very odd I'm able to replicate this with the same control in other forms. The other "factor" I see here is that my image control is a sub-class of image. So the default settings I have for an image class (and the class library it is in) could be having some impact? My thought was maybe for some reason that class doesn't destroy properly.

It only has this behavior when selecting the rotate property on those controls, and there has to be at least 2 of them in the form. I know this all sounds crazy, but the reality is, sometimes crazy things are actually real. This is one of them.

I'll keep looking to see if I can find something else about them that may be contributing.

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

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

RE: Recovery after Run

Well, we can't reproduce and that's part of the problem, so likely your inherited class code plays a role. Notice, I'm not saying I don't believe you, but I and Jockey can't reproduce this error. So there must be something else playing a role. You may be close, but you still haven't put the finger on the exact issue. Within class code anything else might play a role, having nothing to do with pictures at all.

Bye, Olaf.

RE: Recovery after Run

(OP)
Yeah, I understand and that's also why I wanted to see if anyone else could reproduce it.
I might try with just an uninherited form and the uninherited baseclass and see if I get the same thing then. If not, then it's certainly more suspicious of something going on in the inheritance.
It's under control now at least, so I'm happy with that.

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

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

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members!

Resources

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close