Trouble with Classlib 2

[Scott24x7]

Something odd recently started. I've been working on this application for about 2 months now, and starting yesterday, every time I open a form to edit it, and then click "build" after closing it, VFP compiler generates an error stating "<pathname>\baseclasses.vcx is in use and cannot be recompiled".

This just started happening, and now happens every time I edit a form.

If I issue CLEAR ALL from command window, then build it's fine, but it's an annoyance now that every time I open a form if I make any change to any object, I get this message when I try to recompile.
Is this a symptom of something? Is there some way to trace down why this is now happening?
Many thanks.

Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

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

 

[GriffMG]

Have a look here:

thread184-807662

Regards

Griff
Keep [Smile]ing

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

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are not good for you. ​

 

[Scott24x7]

That didn't help. My issue is completely different. I'm not running the forms, I'm just modifying them from the project viewer. In fact, it's worse than I described.
What I just did this second was:

Close VFP 9
Restarted it (the project view opens automatically).
I double click on the form.
The form opens.
I do NOTHING.
I close the form.
I click Build, I get the "baseclasses.vcx is in use and cannot be recompiled". I didn't even change or edit anything. Just opening and closing this form results in this message! And it just started to happen in the last couple of days...
If I use CLEAR ALL from the command window first, then it compiles fine...

Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

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

 

[Scott24x7]

A bit more that I discovered...


I have 3 form classes (more but 3 related to this issue).
If I open a form for editing that is based on the base form (largeformbase) save it, build, everything is fine.

Then I have 2 other forms that are subclasses of that form. (superlargeformbase) and (codetableformbase) Both use as their base class the largeformbase.
If I open either any form that is based on either of those two sub-classes (which do not share any class relationship between them) I get this message about "baseclasses.vcx" in use. Which is interesting also, as those classes are NOT part of the forms class library, but are used on all forms...

I'm not dead in the water because I have to CLEAR ALL available as a work around, it's just very annoying that I suddenly have to do this when using these sub-class-of-a-subclass form. Am I doing something that is inherently bad here by using this method of building form classes? And if so, what is my alternative. I'm open to other ideas, I just thought this was normal to class this way? And it's only 1 layer deep, so I didn't expect that to be a big issue.


Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

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

 

[Dan Freeman]

Well, it really isn't a "big issue". It's an annoyance, sure, but as you say you already have a workaround.

I've seen this behavior periodically, but it doesn't last and I never did figure out what causes it. But I don't tend to build very often, and generally use a custom build program that starts with Clear All, sets working directory, and a few other housekeeping chores.

 

[Scott24x7]

Yeah, but it's clearly related to those forms, and the base classes some how. Very very odd that just loading the form into the editor, and closing suddenly doesn't allow it to work.
This is an Alpha stage application, so there are TONS of builds being applied against it. Being very out of practice, I make tons of mistakes, and frequently have a fatal error that I then think I've fixed, only to run again, and find some other issue. According to the version increment I've built it near 3,000 times in the past 2 months. So that becomes a big annoyance. I also added in another procedure I found which generates an error every time you compile, but at run time it works fine... it's an array. Have tried to resolve that too, as I remember having that years ago also, so I figured eventually I would sort that one out (Maybe just need to declare it?)

But the big issue is the vcx issue. And I fear it will cause some corruption, or that the occurrence is a sign of corruption that will bite me harder later. So that's why I asked if anyone's experienced this, and if so, how to resolve it. It seems so random, on one hand, though I can repeat it predictably, so there is SOMETHING that's common.

Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

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

 

[Olaf Doschke]

Well, starting up VFP, modifying some SCX should not load any vcx into memory, but you could have a startup program via COMMAND=... in config.fpw or _STARTUP that loads a few "framework" classes into memory, or a project hook, which could do the same. And what is the state of the classlibs in the project manager, are nodes expanded? Have you closed them?

Bye, Olaf.

 

[dbMark]

I don't have anything to contribute about the class issue, but a compile issue error, really just an alert, can occur if, as I understand it, an array is referenced in multiple PRG files. Is this what gets reported during the project's compile?
"Unknown [ArrayName] - Undefined"

It's like the compiler doesn't know it's been declared elsewhere in the project's other PRG files. "EXTERNAL ARRAY" declarations in those called PRGs should fix that issue.

My workaround for reports is to add a Dummy.PRG file to the project and in there add lines for each problem array, as in, "PUBLIC ARRAY myArray[1]".

PROCEDURE Dummy
[indent]PUBLIC ARRAY myArray[1][/indent]
ENDPROC

This is only to schmooze the compiler and won't make the arrays PUBLIC since it is never actually called. Then right click on the project's listing for Dummy.PRG and Exclude it from the project. That way the compiler sees it but the code is never compiled into the EXE.

This may not be the best solution but it works for me. Probably better is the method below.
thread184-1362308

https://support.microsoft.com/en-us/kb/124778

"One way to resolve this issue is to create a dummy procedure or function with the same name as the array called in the report. This procedure should never be called* and should have no more than a RETURN statement."
* Add the dummy procedures or functions to the project and then right-click 'Exclude' them so you are sure they won't be compiled.

 

[Mike Lewis]

Scott,

I can't offer any ideas about what is causing this. But you might try closing the project before doing the build (or, not opening the project in the first place). Then do the build from the command line, using the BUILD EXE command.

The point is that this will tell you if the problem is caused by the offending class definition being open within the project manager (for example, because the VCX's node is expanded, as per Olaf's suggestion). In fact, you might find it easier always to use the command, even if you solve this problem (just by scrolling back to it within the command window, and hitting Enter).

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[TamarGranor]

This is an Alpha stage application, so there are TONS of builds being applied against it.

Why? I don't build an application until I'm almost ready to distribute it for testing. I do almost all my testing from the Command window, by issuing DO <my main program>.

The exception, of course, is for building COM objects, where I have to build.

Tamar

 

[Olaf Doschke]

> I fear it will cause some corruption, or that the occurrence is a sign of corruption that will bite me harder later
It's totally normal VFP refuses to either edit or compile a VCX with some class definition it depends on in memory, it indeed protects from wrong compilation or modification results. It's simply an annoyance and you have to find out what loads the base class into memory and doesn't release it.

Follow Mikes advice and test without the project open at all, then you can see whether VFP itself already does something. And yes, like Tamar I typically start within the IDE without build. I have the editor set up to compile at save, but even that is not needed, if you DO a prg VFP creates a missing fxp or recompiles, if the prg is newer than the fxp. And about the same applies to forms and classes. You know you can simply run an SCX via the !/run toolbar button and you don't need to build it.

Bye, Olaf.

 

[ggreen61]

When you open a form for edit, VFP actually creates an instance of the form and all of the classes that it references. These are then held in memory (VFP tries to cache everything to increase performance). This is why you cannot edit a class that is used in a form at the same time that you are editing the form. Now when you build after opening and closing the form, the class is in memory and is not released (it is cached). I have found that the VFP project manager build option has the ability to flush the memory before the build in order to complete the build process. However, if you issue the build command via the console, then the flush does not occur. My guess is that the project manager has the files listed and does a flush of the files in the project. But the command line execution does not have this. If you are building from the project manager, then possibly this is not getting flushed as you might have a hanging reference. The CLEAR ALL command forces the clear of all objects so a build is then successful.

You might try manually issuing a CLEAR CLASSLIB command for each class and see which one is the culprit (it will be successful on the build after the form is opened and closed). It could be multiple and then it is harder to track down.

 

[Scott24x7]

I had already tried variations of having the class lib tree expanded and not expanded, but when you think about it, that should have 0 bearing on it. The property of the class lib sitting in a view of the library shouldn't impact the build.

I'm in the process now of doing what ggreen61 suggested, and issuing CLEAR CLASSLIB to see if I can determine which one is causing the problem, though I'll start with the one it mentions. It clearly has something to do with the two form classes though, where the problem occurs.

On the issue of why I build this way, I like that the version increment occurs, it allows me to better track which builds and which elements have resulted in major breaks or major functionality add (I track it quite closely in documentation). Without this, I have to "invent" one, and I'd rather have the automatic and matched tracking occur.

Lastly, dbMark, GREAT solution. I did just that and it worked brilliantly to make that annoy "stop" in the build from occurring. Most of the time I do build followed immediately bu Run so with this constantly cropping up it was another annoyance. When doing this 40 or 50 times a day, it starts to pile up on lost time and frustration.

Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

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

 

[Olaf Doschke]

>The property of the class lib sitting in a view of the library shouldn't impact the build.

Well, having database nodes expanded or not is deciding about a database being open or not. It's an experiment, that takes minutes, so was worth it.

>I'll start with the one it mentions
It will be the one, why should it be misleading? Its very plausibe a baseclasses.vcx is kept in memory once you opened any form using some baseclass of it.

Bye, Olaf.

 

[Scott24x7]

Olaf,
Agree it only took a second, but I had already tried that before posting my original message.
The thing about the baseclasses.vcx is it is used in the other forms as well. (It's used in EVERY form). But only those two sub-classed-of-sub-classed forms results in problem when opening and closing... so even though baseclasses.vcx may be "stuck in memory" why does it get stuck with those two forms and not the others? I'll see what happens with the testing on the libs, which is why I was thinking it may be something else. Since it's a mystery, we don't yet know why it's causing the problem.

Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

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

 

[Scott24x7]

The plot thickens...

So I tried the CLEAR CLASSLIB baseclasses.vcx and CLEAR CLASSLIB baseclasses both return the message "baseclases.vcx is in use and can not be compiled".

I then went through all the CLEAR options (CLEAR CLASS, CLASSLIB, DEBUG, DLLS, FIELDS, etc) even the ones that would seem to have no impact.

Oddly I discovered if you issue CLEAR CLASS <classname> if the CLASS doesn't exist, VFP doesn't generate an error about the class not existing.
However, when I issue "CLEAR CLASSLIB BASECLASSES" (or BASECLASSES.VCX) VFP REPORTS: "CLASS LIBRARY FILE '<path>'\baseclasses.vcx' is not found."! WHAT???

So I click BUILD again on the project view, and again it continues to report: (See image below):

So I try to clear it by specific ID and it doesn't work.
Still, issuing CLEAR ALL allows it to proceed... Is there some way to "view" the environment that VFP is seeing? I thought a CLEAR MEMORY might also work, but it did not. What more gets cleared by a CLEAR ALL? I also tried RELEASE [CLASSLIB] and RELEASE [CLASS] and CLOSE PROCEDURE none of these had any impact either.

I did a LIST MEMORY and LIST STATUS but those text files showed nothing of any reference to BASECLASSES.

Any other thoughts?

Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

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

 

[vgulielmus]

You can try to open :
- the parent class, or
- the class itself, or
- one of the forms

Not guaranteed, but sometimes removes that annoying message.

Respectfully,
Vilhelm-Ion Praisach
Resita, Romania

 

[Scott24x7]

Here's what I just did...
I thought it might be linked to the Form Class associated with the "Options" under Tools. So I cleared that, closed VFP opened again, opened one of the forms, but again same issue.

So then I set the Template Class to the base form "Largeformbase".

Opened one of the forms as before, still same issue.

So then I decided to make a new sub-class of Largeformbase (which I proved already does not create the error when I open a form based on it in the project).

The only change I made to Largeform base was to add a single text field onto the form and just set the label caption to TEST and the font size to 72, just to make it easy to see.

I created a new form and added to the project based on that sub-class.
When I open that form, make no change, close it, compile the project (which that form is not even called in, it's just sitting in the form list), same issue as before: it generates the "baseclass.vcx" is open and can not be recompiled error.

So it is certainly an issue of sub-classing this form (not saying that happens with all subclassed forms).
I still find 2 things odd: 1) that it is causing a problem at all and 2) that the baseclasses.vcx doesn't seem to be in a state that CLEAR CLASSLIB or RELEASE CLASSLIB can "see it". As issuing those commands results in the message: "Class library file 't;\development\foxtest\baseclasses.vcx' not found.

Which suggests, it's not in memory...
So I'm still stumped by why/how this occurs.
Any other suggestion for troubleshooting? I'm not sure where to go from here....

Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

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

 

[vgulielmus]

Sometimes it happens to me, and I noticed that sometimes when I try to open the parent class, or the class or the form, a warning message to remove the class pops up, and after that I can compile the project.
But no guarantees, and I didn't dig further, because I simply exit and launch again VFP.


Respectfully,
Vilhelm-Ion Praisach
Resita, Romania

 

[Olaf Doschke]

Well, CLEAR ALL clears all, including CLASSLIBS and CLASSES. Indeed CLEAR CLASSLIB only can clear a classlib, when all CLASSes are cleared beforehand (it doesn't cascade the clearing of all classes in the lib).
So CLEAR ALL is the natural way of clearing all classes and classlibs aside of other things like memory, DLLs, etc.

To be more precise, CLEAR CLASSLIB is described as

If instances of classes in the class library exist, the class definitions are not cleared from memory. However, all class definitions that do not have instances are cleared from memory.

And about the same applies to each single CLEAR CLASS. So the class definitions can only be cleared after any instances of the classes are cleared beforehand, and CLEAR ALL destroys class instances, both through releasing variables and all other references. It is the standard solution to the problem.

There is AINSTANCE(laInstances,"somebaseclass") which could tell you instances running, but only those in variables or arrays, nothing that is simply subobject or property of something else. I also tried SHOW and LIST MEMORY and STATUS, no these don't show anything of the internal memory management of instances, which most probably bite you here, and I fear AINSTANCE will also not show anything up, but if it does you would get variable names in the result array. So if you don't find any variable holding any base class reference though AINSTANCE() you know it's some other reference, like the ones the form/class ddesigner creates when you edit a class or form. Which means you only confirm, what we suspect so far anyway: Closing the designer does not release things from memory sufficiently.

You brought up one more thing to investigate: VFP does not find the VCX, so you may have a drive problem, do you have SSD? Someone in german MSDN forum reports missing classes and classlibs at a custommer site, when working there and my suspicion there also was SSD. The only time I had comparable issues it was only about completely missing files, though, not files you see yourself in project manager, but VFP misses during compilation, that would be a new phenomenon.

And were does your baseclass.vcx reside in relation to the pjx? Is it separate from the project home folder? A library shared in several projects, perhaps, like FFC baseclasses? You might have a classloc problem, then.

Bye, Olaf.