Problem with project vcx file

[Bryan - Gendev]

I have returned to my app which I last worked on 10 years ago.
I have been chasing bugs and making slight alterations for the past 3 weeks.
I have rebuilt the project and produced new exe files many many times during these weeks.
Today I get an error on a rebuild or exe creation.

error is [\foldername\_gdiplus.vcx is not an object file]

I have removed the 'old' gdiplusx.vcx from the classes list in my project and copied original (C 2010) vcx and vct files which were used in a previous version of my program to the folder, but the error persists.
Can anyone help to enable me to rebuild my project and produce exe files again?

Regards
GenDev
82 years old

 

[Chris Miller]

If you replace a non working VCX, then please replace both VCX and VCT file from the original, which I think just is the ffc classlib within the Home()+"ffc" folder.

Chriss

 

[Mike Lewis]

Looks like a corrupted VCX or VCT. You might try[tt] COMPILE CLASSLIB <filename>[/tt].

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Chris Miller]

One more thing you could tell us, is whether \foldername\ actually is the same as Home()+"ffc", because then your original _gdiplusx.vcx class library is broken and you could only fix this by reinstalling VFP.

Chriss

 

[Bryan - Gendev]

Thanks Chris
It turns out I had chosen to use another classlib all those years ago - don't know why now.
So I Linked the ffc item and now I'm in business again.

Cheers

GenDev

 

[Chris Miller]

So I Linked the ffc item

There are pros and cons to letting your project link to a class library in Home() vs copying it into your project folder. If it works now, fine.

Chriss

 

[Bryan - Gendev]

Where could I find a dissertation on the pros and cons then?
GenDev

 

[Chris Miller]

Just think about some things and it becomes clear where pros and cons are:

Foxpro is by default installed into a system directory of program files, in which you can't write by default. So building/compiling a classlib it can't be written to it. That's a con for using the class in HOME() as is.

Copying it out to your own project directory the write issue is gone, you now just may have broken dependencies of the classlib to base classes it inherits from, that you left in HOME() and didn't copy out.

The second problem may be worse than the first, so you can decide to give yourself permissions to write into the installation directory. But that makes the istallation prone to attacks or just unintentional breaking of files in it.

There you can see it becomes harder to decide, but here's my main point. Put aside all thoughts and problems vs solutions, you already made a decision once, why don't you trust that?

I read between the lines, you say you linked to the class library in HOME() now. So that wasn't the case previously. The project as you found it was not doing that, it had a copy of the FFC class library. So why change that?

Copy the _gdiplusx.vcx and _gdiplusx.vct into your project folder and be done. If you think the corruption of the VCX proves this earlier decision was wrong, then you have the wrong idea that the breaking of a VCX was inevitable or the root reason for that is it was not kept at it's original place. Nobody can say why the compiler didn't like the copied VCX anymore, but one good thing of it being a copy is you have an untouched original in HOME() you can copy again. It's not ever sure nothing breaks, but it's unlikely a libary you don't touch breaks.

The old situation was working once, so I doubt you used a class from _gdiplusx.vcx/vct that has a dependency to another vcx/vct library that you didn't also copy into your project file. Well, so either you did also copy over the dependent libraries or there are none. In any case jsut refreshing the copy of the _gdiplusx library will fix your problem, too.

You can see dependencies of libraries to others with the class browser. Opening _gdiplusx.vcx in the class browser shows a treeview of class inheritance and makes clear at first sight, that there are no dependencies with other libraries. The root class gpbase is based on custom, not on a class of another base library, which means the _gdiplusx library is self contained without dependencies. It will depend on gdiplus.dll, but that's not the dependency on VFP files that would require to copy over more files from ffc.

And now you see maybe the major thought is about dependencies. You could also cover that by always copying over the whole ffc folder into your own project, when you use any one ffc class. In the pjx itself, only include a library of which you use a class, the rest will come into your project, if dependencies are existing. Otherwise you may have a bunch of unused files in your project directory, but they just sit there without harming and they don't blow up the size of your EXE, too.

Chriss

 

[Chris Miller]

I'll not hold back the only thing that speaks for using ffc classes as they are and where they are: The usage of HOME() in ffc code.

Here's all vcxxes and prgs using HOME(), I searched the ffc folder for HOME( only to also catch things like HOME(1), etc, which I think are not used, but you never know:

You see, the _gdiplus library is not involved in this dependency. The advice to generally copy over ffc has to be taken with caution, though.

The final thought is about project portability and independence. If you make the link to the HOME() folder and think the HOME() function makes it portable to other computers anyway, you ignore the fact the project items themselves are referred to by full absolute path, so on a computer where HOME() differs from yours, your project doesn't find FFC classes of your project, you're bound to the same HOME() directory. The ffc classes find themselves mutually inside the ffc folder, wherever VFP is istalled, wherever HOME() is. But you will include at least some into your project just by reference and not file copy, in case you do that you depend on a constant HOME() to keep your project portable, otherwise the project items are not found when you open up the PJX.

You could then argue choosing the same HOME() is not difficult, even keeping projects on the same computer isn't hard to do. Well, you never know.

Every problem with not found files can of course be addressed by locating them, so it's not a big deal, therefore the other argument is about keeping originals at their original state. Unless you do a change that's advised for fixing a known bug, changes you do for a project shouldn't influence other projects. It depends which things you value higher than others, what's the best choice and even, whether it pays off to change the code of a copied ffc to not use HOME() but a function that's based on the project homedir.

In your case a copy into the project folder would be my first choice, because there is no HOME() dependency of the library, so don't introduce one by pointing to the library in its home location, copy it and make it part of your project folder, not just a project item that points to HOME().

The final crux is, that the HOME() function can't actually solve what it is intended to solve, once a project uses ffc classes, that are in a project folder outside of HOME(), well, and to put your projects inside the VFP installation is not a solution, either.

Chriss