FPC compatibility in general

[circular17]

Having a folder with copies of FPC packages that are tweaked with mclasses unit leads to incompatibilities when using packages that are not included in the folder.

Two solutions to avoid this problem are :

• prefixing unit names with mse
• adding bridge classes to plug together Classes and mclasses

As Fred suggests we can compare Classes and mclasses to see what are the difference and see what really needs to be tweaked.

If no tweaking is needing it would simplify to remove the files from the compatibility folder.

[fredvs]

prefixing unit names with mse

Imho, only the ones where deep change was made in code.
If only was added in uses section mclasses, imho, your bridge is perfect and the files may be deleted.

[fredvs]

I am a little afraid to break compatibility for msegui himself.
If you dont link to the original msegui tweaked fp* it could have problems if not only mclasses was added.

What I propose and it works perfectly, is to rename all the tweaked fp* into msefp* and in msegui code replace all call to fp* by msefp*.

Tested and works like charm.

So for himself, msegui will use msefp*, and you, if you want, you may use the official *fp + your bridge.

[circular17]

I would say that for now, I prefer not having to rename units because that would add a lot of $IFDEF in BGRABitmap.

I understand you don't want MSEgui to be broken when using original FPC files. Though in the long run, avoiding those duplicate files would reduce maintenance and updates.

When I have the motivation, I will have a look and try to understand what is the point of mclasses. Maybe my idea of removing the compatibility folder is impossible, but I would prefer to make sure of it.

[rchastain]

Having a folder with copies of FPC packages that are tweaked with mclasses unit leads to incompatibilities when using packages that are not included in the folder.

For easier discussion, please could you provide a test project which shows that problem?

[rchastain]

When I have the motivation, I will have a look and try to understand what is the point of mclasses.

Yes, that is what we have to do. I will take a look today.

[circular17]

For easier discussion, please could you provide a test project which shows that problem?

Here is a sample program:

program testzipper;
{$mode objfpc}
uses
 {$ifdef unix}cthreads,{$endif}
 zipper in 'C:\lazarus\fpc\3.0.4\source\packages\paszlib\src\zipper.pp';
 
var 
  unzipper: TUnZipper;
  
begin
  unzipper := TUnZipper.Create;
  unzipper.FileName := 'somefile.zip';
  unzipper.UnZipAllFiles;
  unzipper.free;  
end.

which does not compile:
zipper.pp(835,60) Error: Incompatible type for arg no. 2: Got "CLASSES.TStream", expected "MCLASSES.tstream"

[rchastain]

Here is a sample program:

OK, thank you.

FYI, I found an interesting example in MSEuniverse:
https://github.com/mse-org/mseuniverse/tree/master/tools/mse-installer

[circular17]

Ah yes I remember you mentioned it. I'm going to look at it now.

Get an error opening the project:

And an error when compiling:

Compiling mse-installer.pas
Fatal: Can't find unit system used by mseinstaller

[rchastain]

@circular17
Yes, I had the problem. Let me some time, I will provide a corrected version.
If you want to do correction by yourself, you have (if I remember well) 1° to remove everywhere in mfm ow_autoscale and ow_fontglyphheight values 2° to edit macros in project options.

[circular17]

Ok I will try that.

Well I don't know what to do to fix the System-not-found error.

[rchastain]

Well I don't know what to do to fix the System-not-found error.

In "project options, make, directories," replace $TARGET with $TARGETOSDIR.

[rchastain]

There are still other problems (Identifier not found "tmacrolist", etc). I solved them yesterday like a butcher. I am trying to do it in a better way now.

[rchastain]

This one is not so simple to fix:

globmodul.pas(155,60) Error: Wrong number of parameters specified for call to "add"

So temporarily, I comment all these lines:

fmacro.add(['HOMEDIR'],[removeendpath(sys_getapphomedir)]);

[circular17]

Changing $TARGETOSDIR didn't work for me.

I suggest that if you find a way to fix it that you propose your changes to the repository.

[rchastain]

Changing $TARGETOSDIR didn't work for me.

Did you fix the macros?

I suggest that if you find a way to fix it that you propose your changes to the repository.

OK, I will do it.

[fredvs]

Yes, I perfectly understand that but I dont understand if Geany uses the same command line as MSEide that the result can be different.

[fredvs]

Did you see last picture I added later in previous post?

[rchastain]

Fred my friend, I am tired. I will go to sleep. If you want, you can try it by yourself.

https://github.com/almindor/lnet

Try to compile the lmimewrapper unit in an empty MSEide project and (for example) in an empty Lazarus project.

Good night!

[fredvs]

Hello Roland.

Good night.

OK, I will try.
About Geany, I did try to compile mse-installer.pas and it was OOTB, using the command line of MSEide:

But maybe I miss something.

Re-good night.

Fre;D

[fredvs]

Try to compile the lmimewrapper unit in an empty MSEide project

Yes, indeed, each unit that uses classes must add mclasses.
Hum, that is a big problem...

I really hope that the Circular's Bridge will do miracles.

[circular17]

I guess I have found a solution:
#11

[rchastain]

I guess I have found a solution:
#11

OK, I start to test your modifications.

[circular17]

Note that if you test with BGRABitmap you need to change in BGRAClasses the following types like this:

  TStream = Classes.TStream;
  TPersistent = Classes.TPersistent;
  TStrings = Classes.TStrings;
  TStringList = Classes.TStringList;

[rchastain]

I opened, compiled, run many projects using the code from your repository: no problem detected.

Je ne sais pas comment tu as fait ça, mais en tout cas, chapeau ! Ce qui m'étonne, c'est que Martin ait inclus ces unités dans MSEgui alors qu'il était possible, apparemment, de s'en passer...

[circular17]

Cool content que ça fonctionne !

Héhé j'ai plus d'un tour dans mon sac. J'ai utilisé des techniques de "magicien", si l'on peut dire. C'est-à-dire des choses qu'on n'est pas censé faire, mais qui combinées peuvent aboutir à une illusion vraisemblable : remplacer des fonctions virtuelles au lieu de les hériter, tout en les laissant virtuelles pour qu'on puisse dériver encore, en utilisant des classes ayant apparemment le même nom.

Je suppose que Martin se satisfaisait juste de hacker les unités en rajoutant mclasses. Cela fonctionne si on est peu à utiliser le projet parce qu'on peut toujours rajouter des unités, mais cela a ses limites. De ce fait, à mon humble avis, il n'a pas visé la compatibilité, comme par exemple le fait qu'il ait ajouté une propriété memory à l'objet de base tstream, ce qui ne me semble pourtant pas nécessaire.

[circular17]

Je précise que je ne porte pas un jugement sur son approche, je comprends qu'il ait voulu avoir la latitude de changer ce qu'il voulait afin d'obtenir exactement ce dont il avait besoin.

[fredvs]

Sincèrement je suis hyper impressionné par vous deux.
Circular, ta solution est géniale, je ne sais pas pourquoi Martin ne l'a pas utilisée.
Roland ta profonde lucidité reste légendaire .

Fre;D

[fredvs]

OK, let say it in International English: WOW

I just did test with last pull of Circular, trembling when launching the compilation of a big application, and boom OOTB, without cry, clean , fluid, logical.

Congrats Magic-Circular and I think we have to upgrade the msegui version number to 5.0.1.

[JonnyTech]

let say it in International English

What did we miss?

[circular17]

That we are happy about the solution and wondering why Martin did not try that.