Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Recovery after Run

Status
Not open for further replies.

Scott24x7

Programmer
Jul 12, 2001
2,795
10
38
JP
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]
 
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]
 
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]
 
I have only browsed this thread briefly, but this sounds like you're missing a Clear Resources somewhere.
 
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.


 
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]
 
Scott,

Code:
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
 
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.
 
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]
 
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.
 
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]
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top