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

 

[mjcmkrsr]

Hi,

Is your T: a local harddisk or some kind of LAN drive or even NAS?
I had this kind of problem with a NAS - in fact it was a matter of cache. This wasn't emptied fast enough and I had to flush it manually all the time. Since then I use local hd for development.

hth

MK

 

[Scott24x7]

MK,
That's interesting.
Actually it is a local drive, but it is a RAID array. Let me try it on a separate local drive and see what happens there. My expectation is that the problem however, will persist. The reason being is the clue is I can repeat the problem ALWAYS wish sub-classed forms of my largeformbase (so to put another sub-class-of-a-sub-class form).

It interestingly clearly does not happen with sub-class-of-sub-class objects however, as I have several of those in other locations as well.
-S

Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

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

 

[Scott24x7]

Hi MK,
Tried that but same result. So it's not an issue of drive or cache...

Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

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

 

[Olaf Doschke]

You might give this classloc check a try:

LOCAL loFile

CLEAR 
FOR EACH loFile IN _vfp.activeproject.Files
   IF loFile.type $ "VK"
      USE (loFile.name) IN SELECT("curclasslib") ALIAS curclasslib
      SELECT curclasslib
      SCAN
         IF !EMPTY(curclasslib.classloc) AND ADir(laDummy,ADDBS(JUSTPATH(loFile.name))+ALLTRIM(curclasslib.classloc))=0
            ? "Classloc not found:", curclasslib.classloc, loFile.name, curclasslib.class
         ENDIF 
      ENDSCAN 
   ENDIF 
    If ADir(laDummy, loFile.name) = 0
       ? "Missing File:",loFile.name
    EndIf 
    
    If NOT (loFile.name = JustPath(JustPath(_vfp.activeproject.Name)))
       ? "Outside Project Home Folder:",loFile.name
    EndIf 
EndFor

Open the project and run this eg from command window. Copy from here and paste via CTRL+A/CTRL+V, then select all CTRL+A, right click and "Execute Selection".
Or of course put it into prg and run it from there. Being part of a project even has the advantage starting it through project manager makes it the _vfp.ActiveProject. An extended version of that fixing the references is part of any of my projects.

It will output missing files and show files outside project home, but mainly check, whether classloc locations are pointing to existing files. In this simple version it'll fail on classlocs being absolute paths (as something like D:\myproject\mylibs\H:\myframework\baseclasses.vcx won't ever be found, of course), but that's good anyway, as any location of base classes, which can't be relative to a classlib is a bad design in my definition, my projects are self contained, I tend to also never use ffc classes.

If VFP doesn't warn about missing files when you open the pjx you also won't find missing files here, but OPEN PROJECT does not check for missing files referenced by classloc, so these are the most likely error this code would reveal.

I bet you won't see anything, but if you do, you might get track on something wrong and fix the classloc references.

Bye, Olaf.

 

[GriffMG]

That's a nice useful bit of code, thank you and have a star

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]

Thanks, Olaf agree with Griff this is a brilliant bit of code. But your prediction was also correct... it did not reveal a problem.
I'm now onto something, which looks like might be an issue with some other sub-classes that are not form classes, that are being used across class libraries. I didn't think this should be an issue, but it now looks like that's what's happening. I'm still trying to sort it out, but it looks like it's being caused by a navigation menu which has buttons from 2 separate classlibs, one of which has components from it's own classlib and another class library combined to make a 3rd object...

About to test that out, and see if I can resolve the issue.


Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

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

 

[Olaf Doschke]

OK, so everything fine from that perspective. Anyway,m, the check for missing file should be put as first, obviously a missing vcx can't be USEd.

Bye, Olaf.

 

[Scott24x7]

I think I'm narrowing in on the issue... I have several repeatable behaviours, though I just ran into another oddity that "worked fine" a couple of time, then suddenly developed the same issue. So I'm setting another part of the theory, but I'm rather certain I have 75% of the issue figured out. Based on what I'm finding if none of the rest of you have this problem, you're either doing something that's more intuitive than it is to me, or like Tamar, you don't notice it because of the method of build you're using. It probably isn't specifically detrimental. And maybe I'm spending more time on this than I should, but I just don't like having this behaviour occur without an explanation.

I can certainly find "culprit" classes, though VFP is being a bit errant in it's reporting of the issue accurately. It complains about "baseclasses.vcx" being in use, but it's actually caused with other classes use the class (particularly, I'm finding "container" class additions to be quite troublesome, and a key link to the issue, especially when coupled with label classes, which are used in just about everything.)

When I nail this (and I think I'm pretty close now) I'll post up the problem and the resolution... it might even be worth an FAQ.




Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

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

 

[GriffMG]

Have you considered not using classes, or using them less?

I'm wondering if, is it possible, you have developed a nested approach
where one class is dependant on another class, which is dependant on the
first class and thus neither can be compiled because the other is still being
compiled - or something bizarre like that?

P-)

I am not a devotee of the whole OOP approach, being a luddite, I do
something close to structured code (one entrance, one exit, top down, stepwise)
with as much attention to variable names and stuff as I can, but not as many (up to date)
comments as most would like - and no pseudo code as far as I can remember.




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]

Griff,
The problem does seem to be related to placing objects into containers in sub-classes, where the container is a sub-class as well.
Not using an OOP or non-visual approach in my view defeats the purpose. Flattening the object model a bit, I'm ok with. But interestingly, the thing that lead me down the path first was the label object, mostly because it is so heavily used, though it is not specifically the problem. "Nesting" 2 or 3 layers deep I did not think should be a significant issue, and at run time, of course it's not. In fact at design time, doesn't seem to be either, it's a compiler issue, which is resolved by a "CLEAR ALL". So to reverse engineer everything back to Fox2.6, I might as well just go back to FPW2.6. I may keep my "layering" as is once I've resolved what is causing it, and ignore the error. It all started from sub-classing a form class, which then had some "new" objects I added to it which essentially are containers that are meant to provide an improved experience to the user. These two containers are a "pop-out" on-screen help system that you can access by clicking a "?" button from the topline menu, and is context sensitive to the screen/tab you are on. It works great, and is a nice interface enhancement, but when it became containers within containers (as I wanted a more modern "button" feel, I've created my own button class using containers and text or images, where appropriate. And I have a text button and an image button which are separate (because I can't get a button without a border on it!)

One issue seems to be, when you have containers on a container that is on a form, for example, and the "top container" (the one furthest down the tree) has a text label on it, and you just let the system name the label like "Label1", and then the container below it also has a "label1" and then the form somewhere on it maybe has a "label1", now the should all be "hidden" from each other by the object they are contained in, but I can now prove that the compiler doesn't see it that way... and that is incredibly annoying. (At least it doesn't see it when determining if a class has been opened, which 'label1' is which, and generates then doesn't release the object(s) from memory as it should, resulting in this error when building from the project's "Build" button (so may also be a specific interaction with the project Manager). Don't know if I'll ever get an answer to either of those, but I am looking for the solution now.

One thing that seems to resolve the issue is, let's say I have a "form class library" and a "baseclasses library" (really for objects you put ON forms, but no forms in the lib) and a "navigation library". So putting objects from baseclasses onto forms is no problem. Even subclass the form, all is well. BUT in the navigation library, base those objects first on a container (from baseclasses) then add a label and a text box (and for good measure, add a container to that container, and put an image on it, for instance). Now put that class on your lowest level form class, and all is fine. BUT open a form that is sub-classed to that form, and when you close it and try to compile, boom.

But I found if, in the Navigation sub-class, I make a new "Container", and I make a new "Label" and "Textbox", and I use those objects within that class (no matter how much I stack them up), and then place THAT on the form and the subform inherits it, then... all is well.
Incredibly incredibly annoying.

It actually seems to diminish the value of sub-classing. I never sub-class more than 3 layers, and it's only after the 2nd layer it becomes an issue (as I can tell). But I'm not 100% complete with testing this theory yet. But so far, all I have described is resulting in preventing the error message from occurring, and the objects getting stuck in memory.

Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

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

 

[GriffMG]

You seem to be describing exactly what I suggested "I never sub-class more than 3 layers, and it's only after the 2nd layer it becomes an issue"

The using classes less was tongue in cheek.

I wonder if you could compile all your project elements individually, and see if one/some would not compile because it was dependant on
another being compiled (i.e. available in object form) first.

I'm probably talking shot, so don't worry about telling me one way or the other.

B-)

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. ​

 

[Olaf Doschke]

Indeed you trigger some memory. I think I remember an issue with the container class, I just don't know what it was.

Bye, Olaf.

 

[Scott24x7]

Well, it compiles every time if I CLEAR ALL
The fact that I have to clear all bothers me... it's probably not worth worrying over.

I've now reached the conclusion, the problem is in subclassing the form, which is the most annoying of all... I wanted several forms that carry certain attributes, that would be easy to change/modify (modernize) later by changing 1 form. But now it seems, that's not going to work, because I still have a problem with the baseform having the objects from the other classes that create this cascading effect... this really all started after I added the two forms as subclasses... now I'm back full circle, after getting pulled down a rabbit hole regarding containers and labels, I made it "work" on the first sub-class (from base class) form, but all sub-classes of that form result in the issue, even when I get them working on the parent... really frustrating.

So now I'm faced with: put up with the error and issue a CLEAR ALL every time before I click the build button, OR make the main forms that I use each their own class without subbing from one another. The latter is probably cleaner in both regards, but not as "useful" as OOP "should be" (in my view).


But it does mean I can stll subclass across the other object types. It's just the forms that are actually the issue...

Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

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

 

[TamarGranor]

FWIW, besides building only rarely, I also type CLOSE ALL, CLEAR ALL many times a day. To me, that's a sequence that should be executed after any significant work. With IntelliSense, it's not that many characters:

CLOS A
CLEA A

It also sounds like you're using the auto-incrementing build numbers as a kind of version control. I'd recommend using actual version control. I started using Mercurial a few years ago because it was the first VCS I'd encountered that didn't seem to be more trouble than it was worth. It's saved my bacon a few times and I find I'm using it for more and more things.

Tamar

 

[GriffMG]

I have an idea you can put a project 'hook' in that will issue the 'clear all' for you before each build.

That way you can at least forget about it

thread184-255993

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]

Tamar,
You hit the nail on the head there... I've not used Mercurial, but previous VCS's have been exactly that -- create more work than they are worth. (My driving philosophy of software is that software gets used when it's easier to use the system than not use the system). I type CLOSE ALL, CLEAR ALL, CLEAR all the time, but not for this, and really didn't want to have to add a new layer. It may seem odd, but for me it's a "rhythm & flow" interruption I'd rather not have to mess with. I have very stringent backup and documenting methods. So much so they basically make VCS obsolete, and to be fair, they are less work than previous VCS I've used. The development platform even gets backed up daily to a private server half way around the world (for me), and I can increase its frequency if needed, but that generally isn't an issue. There are also 2 local backups that run, one to a local drive for those "oops" moments, and another to local server, triggered daily or more frequently if I need them to be.

Griff,
The hook class sounds interesting. I've heard of them in the past, but never really grasped or understood them, but if they resolve this problem, then I will certainly give it a go.
Cheers,
-S

Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

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

 

[GriffMG]

I should do it with a hook, but I do it manually, before each build I have an excluded routine that I run to remove
any lingering traces to local databases and printer stuff (so last year).

The idea of a project hook is that it would be compulsory, unavoidable.

I am so used to running my setdir, before I do the build, I don't think it would help me.

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]

Griff,
So my first time working with the project hook. All very exciting. Except one thing... I put a CLEAR ALL in the BEFORE BUILD event, and it creates the error that:
"Cannot clear the object PROJECTHOOKBASE because it is in use...
Wow... so it seems it can't clear all because it would have to clear itself as well, and since I was unable to successful stop the issue by issuing a "CLEAR CLASSLIB <listed all the classlibs>" I'm just "looped back" to another dead end, since I don't see how a clear all can be issued from any event in the Project Hook because it's actively running.


Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

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

 

[GriffMG]

so you have a hook thingie stopping you issueing a clear thing or somesuch?

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]

Yeah, it's like issuing a REFRESH() from a REFRESH method...
I"m sure you all think I'm crazy by now, but it is an interesting education on how much of the internals work. Just so frustrating there isn't a simple solution to this that doesn't require interruption every time you build...


Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

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