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]

Ahem

Do what I do, and run a procedure before each compile which includes this clear (for me it's a procedure that does the data environment and printer settings)

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]

Well I don't really have anything else (at this point) that needs to be "done". The project hook class was a great idea, until it didn't allow me to do what I was looking for.
I have 3 options:

1) Change my form classes to not subclass from one-and-other, and rebuild many of my forms (my least favorite option)
2) Change my "habits" and don't build with frequency (not an option I'm crazy about because I still feel it adds value to my process, and it reduces "production time" weirdnesses)
3) Put up with issuing the CLEAR ALL (at least until I find some other solution)

For now, option 3 is kind of it, but it really feels like "losing". I hate that.


Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

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

 

[Scott24x7]

Oh, I left out Option 4...

4) Abandoned VFP development, in favor of some other modern platform. (Not desirable, because of the time investment and learn curve involved...) But it is an option I need to consider over the longer term...

Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

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

 

[Olaf Doschke]

Well, I could have told from the beginning the projecthook can't clear all. But you can CLEAR ALL in a prg, like a shutdownframework.prg or resetIDE.prg, I have such things to get the IDE into a normal state after any test session, that turned out problematic.

Going back to an earlier post:

It complains about "baseclasses.vcx" being in use, but it's actually caused with other classes use the class

That should be clear from the outset, you never run a class from baseclass.vcx itself, if you have your basicly unchanged first inheritance of each base class in there, but the classes are used in most any form or further class of course, being used as component, not as parent class is enough to make that in memory reference hindering you to build.

As was said before the Build button of the project manager would clear everything from memory it can, that was new to me and I begin to doubt it.

I still haven'T found the issue with the container class, but it was something along the lines to not subclass it more than once and put a secondary class of it inside another container. There is almost no need to do so, the base container class has the purpose to contain further things and what you'd normally want from the container is having no border and being transparent, that can be done on your base container class and then there is nothing further to do.

My first try is quite some success, I got a C5 error puzzling together some containers in containers and just saving the form caused invalid memo file followed by C5 error. But I doubt that was the cause, that was pure coincidence, I'm rather after the "vcx in use" error than problems even saving a form. I'll have to delay further experiments to later.

Bye, Olaf.

 

[TamarGranor]

Regarding Mercurial, when you have time to look at it, do yourself a favor and start with Rick Borup's papers on the topic:

http://www.ita-software.com/foxpage.aspx

This is the one to start with:

http://www.ita-software.com/papers/Borup_Mercurial_Published.pdf

Tamar

 

[Scott24x7]

Thanks Tamar, I'll give it a go. I've got a "presentation deadline" coming in 4 days, so I'll take a look at it after I've passed that milestone, as at the moment I'm trying to get a certain level of functionality and stability into the system before then.

Thanks for the info on the subject.

Olaf,
One thing I like about OOP is of course inheritance, and it's great to have a Base, but different sub-classes where behaviour/appearance of an objected is repeated, especially when there is heavy activity in methods or procedures, that is consistent, but variable across object purposes. Containers are the core of that in many cases, but it's not just limited there. I also have 3 "Label" objects, partly because of the silly behavior of VFP if a label is "Disabled" it puts that annoying shadow effect applied to it even with that property is off. So I have a "LabelBLack" that I use instead when a field is always disabled (the black label is a visual reference that you can't modify the field that is next to it). So their label properties remain the same. I suppose I could put that in a refresh clause instead, something like:

IF ThisForm.Editing = .T.

This.ForeColor = RBG(128,0,0)​

ELSE

This.ForeColor = RGB(0,0,0)​

ENDIF

And then have only one class... but it feels "cleaner" to just have an object that doesn't change its own properties. So often times the sub-of-a-sub is to manage some other part of VFP that is otherwise non-intuitive or presentes a nuesance in having to constantly change attributes to make it fit a scenario. If I need an object more than once, I tend to want to see if there is a way to reasonably sub-class it.

Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

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

 

[Olaf Doschke]

Scott, I'm not saying that you should have a flat hierarchy in general, I am saying the container has a known bug in inheritance. There's nothing similar for Labels or other native classes, though. The problem of the container is based on the fact it's the only control that can be put inside itself.

In regard to the readonly/editmode topic: The typical solution is SetAll enabled .t./.f. and to prevent labels to get disabled you let them have enabled_assign method rejecting the change or you let all controls react to an editmode property, eg on form level, yes. That's rather behaviour, you wouldn't replace objects at runtime just because of a mode change.

Bye, Olaf.

 

[Scott24x7]

Olaf,
Maybe I missed it if you mentioned it before, but it's first time I've heard there is a known bug for the container class. And the point you make about it being the only one that can be put inside itself does make sense, and I hadn't thought of it this way before. And all the issues I've been having do involve container objects, I now see your point. And of course with VFP there will never be a fix for this...
Is the same problem true of OptionGroup and CommandGroup, since they are fundamentally container classes as well, which can also be placed in themselves?

On the plus side, as I mentioned before, it only impacts a sub-classed form that has a container object on the subclass form, and the only impact is that it doesn't automatically remove the objects from memory, which is resolved with a CLEAR ALL. At least we got to the bottom of it, and that at run-time it doesn't really effect anything.

Actually for labels I just always set them as .T. for enabled, and there is no refresh on them (unless I change their visible property to something if I need it on occasion to be visible or not visible.) But their color state doesn't change. But I used to use labels placed on the form as either T/F enabled for color purpose, but then that daffy shadow on disabled showed up, and I just wanted a black label to show that it's not editable to start with. It's no big deal to have 2 class for this one... it saves a little time.


Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

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

 

[Olaf Doschke]

I don't know what you're saying, Optiongroups can contain more than the default 2 options, but not further optiongroups, same goes for commandgroups. I don't talk of visually inside, I talk of being a child object with its .PARENT propety pointing to the parent container. Many controls are containers, but only the container can contain itself. Formsets can contain forms, but forms can't contain forms, the grid contains columns and they can contain any control, even grids, but a grid is never a direct parent of another grid, same goes for pageframe->page->pageframe. That is possible, but only because pages con contain any controls including pageframes.

And yes, if you had enough of investigatin doing CLEAR ALL before build is a very general solution to that error message, you can't put that into a projecthook, but into a resetID.prg. I can also start VFP in less than 1 seconds from SSD drive, having removed the reference to gotdotnet.com - alternatively turn off loading the task pane at VFP start.

Bye, Olaf.

 

[Scott24x7]

Ah, right I see your point now.
It's too bad they don't allow the button baseclass to set the border off entirely. That would solve 90% of my problems...

Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

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