FPC compatibility in general about mseide-msegui HOT 60 CLOSED

Sorry to come a few late in the game but what demo/test are you trying to compil and that gives all the errors?

It's the MSE installer from MSEuniverse.

https://github.com/mse-org/mseuniverse/tree/master/tools/mse-installer

I suggested to use that project to experiment as an example (because I noticed that it uses zipper and also units like msegraphics, mseformatjpgread, mseformatpngread, etc).

from mseide-msegui.

Ha, ok, I will jump into it tonight.

To save your time, here is the whole project fixed (with some parts of the code put in comment).

mse-installer-202004181804.zip

There are two projects in it (mse-installer.prj and setup.prj). Both compile and "work" (open without crash).

By the way, there are very beautiful things in MSEuniverse.

from mseide-msegui.

I guess I have found a solution:
#11

from mseide-msegui.

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.

from mseide-msegui.

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.

from mseide-msegui.

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.

from mseide-msegui.

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"

from mseide-msegui.

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.

from mseide-msegui.

As I am not very good at git, and as the project isn't really fixed, I prefer not to touch to the git repository for now. So here is the project retouched. It doesn't compile, because the zipper problem is not solved. I let you find and experiment your own solution.

Edited. File removed. See new version below.

from mseide-msegui.

Ok I compiled it. There was some missing parameter to tbitmap.loadfromfile (just an empty array). Also I retreive the RES files from the original folder.

I get the following error at runtime:

I take a break.

from mseide-msegui.

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;

from mseide-msegui.

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

from mseide-msegui.

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

from mseide-msegui.

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

from mseide-msegui.

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.

from mseide-msegui.

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.

from mseide-msegui.

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?

from mseide-msegui.

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

from mseide-msegui.

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

from mseide-msegui.

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

from mseide-msegui.

Ok I will try that.

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

from mseide-msegui.

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

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

from mseide-msegui.

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)]);

from mseide-msegui.

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.

from mseide-msegui.

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.

from mseide-msegui.

For me, once I have made all that modifications, I fall on the zipper problem:

PPU Loading /usr/lib64/fpc/3.0.4/units/x86_64-linux/paszlib/zipper.ppu
PPU Source: zipper.pp not available
Recompiling zipper, checksum changed for zstream
main.pas(109,11) Fatal: Can't find unit zipper used by main

from mseide-msegui.

To fix the macros problem, I simply selected Active group 4, which doesn't exist. But maybe it won't work for you.

from mseide-msegui.

For me, once I have made all that modifications, I fall on the zipper problem:

PPU Loading /usr/lib64/fpc/3.0.4/units/x86_64-linux/paszlib/zipper.ppu
PPU Source: zipper.pp not available
Recompiling zipper, checksum changed for zstream
main.pas(109,11) Fatal: Can't find unit zipper used by main

Did you remove the in '...' after the zipper in uses clause?

from mseide-msegui.

Did you remove the in '...' after the zipper in uses clause?

I wasn't speaking of the short example that you provided, but of main.pas (mse-installer.prj) and setup.pas (setup.prj).

from mseide-msegui.

I wasn't speaking of the short example that you provided, but of main.pas (mse-installer.prj) and setup.pas (setup.prj). There's no in there.

Oh I see. Well you need to have zipper.pp in msegui\lib\common\fpccompatibility. With the mclasses tweak.

from mseide-msegui.

Oh I see. Well you need to have zipper.pp in msegui\lib\common\fpccompatibility. With the mclasses tweak.

Yes, that's what I did yesterday. But if I well understand the first message of the discussion, there are problems with that solution, isn't it?

from mseide-msegui.

There was some missing parameter to tbitmap.loadfromfile (just an empty array).

Thanks for the tip.

I get the following error at runtime:

Yes, there were invalid properties. Even after I removed them, there still was an error, I don't know why. My trick in that case is to change randomly a value in the object inspector (in this case I reset the options to default options) and save the file.

Here is the valid mfm.

main.mfm.zip

from mseide-msegui.

A first view of differences between classes and mclasses:

{ classesh.inc } TPersistent = class(TObject,IFPObserved)
{ mclasses.pas } tpersistent = class(TObject{,IFPObserved})
{ classesh.inc } FObservers : TFPList;
{ mclasses.pas } //    FObservers : TFPList;
{ classesh.inc } TComponent = class(TPersistent,IUnknown,IInterfaceComponentReference)
{ mclasses.pas } tcomponent = class(tpersistent{,IUnknown,IInterfaceComponentReference})
{ classesh.inc } function GetComObject: IUnknown;
{ mclasses.pas } //    function GetComObject: IUnknown;

from mseide-msegui.

Changing $TARGETOSDIR didn't work for me.

Please use the brackets: ${TARGETOSDIR}

I fall on the zipper problem:

@rchastain did you try with last commit of mseide-msegui?

from mseide-msegui.

Sorry to come a few late in the game but what demo/test are you trying to compil and that gives all the errors?

from mseide-msegui.

@rchastain did you try with last commit of mseide-msegui?

No, not yet.

from mseide-msegui.

Ha, ok, because all the missing files (zipper, etc) where added.

from mseide-msegui.

Oh I see. Well you need to have zipper.pp in msegui\lib\common\fpccompatibility. With the mclasses tweak.

Yes, that's what I did yesterday. But if I well understand the first message of the discussion, there are problems with that solution, isn't it?

Not exactly. The problem comes if the file does not have mclasses after Classes in uses clause. If someone uses the file from FPC, it won't have mclasses for sure.

from mseide-msegui.

A first view of differences between classes and mclasses:

{ classesh.inc } TPersistent = class(TObject,IFPObserved)
{ mclasses.pas } tpersistent = class(TObject{,IFPObserved})
{ classesh.inc } FObservers : TFPList;
{ mclasses.pas } //    FObservers : TFPList;
{ classesh.inc } TComponent = class(TPersistent,IUnknown,IInterfaceComponentReference)
{ mclasses.pas } tcomponent = class(tpersistent{,IUnknown,IInterfaceComponentReference})
{ classesh.inc } function GetComObject: IUnknown;
{ mclasses.pas } //    function GetComObject: IUnknown;

So Martin removed some interfaces. Ok.

from mseide-msegui.

Not exactly. The problem comes if the file does not have mclasses after Classes in uses clause. If someone uses the file from FPC, it won't have mclasses for sure.

OK. I didn't understand correctly.

from mseide-msegui.

https://github.com/mse-org/mseuniverse/tree/master/tools/mse-installer
I suggested to use that project to experiment as an example

Ha, ok, I will jump into it tonight.

from mseide-msegui.

Ho, that will be very useful, I just load the prj now and there are tons of error messages.

Imho, this project is very old and is not up-tp-date with last msegui versions.
Thanks, Roland, I will try with your file.

You are more than welcome to commit your fixes in mse-org/mseuniverse.

from mseide-msegui.

You are more than welcome to commit your fixes in mse-org/mseuniverse.

Yes, when I am ready I will do it. For now, I try things.

from mseide-msegui.

Some news.

I played with a MSEgui demo using the lNet library. After I made the changes to fpccompatibility folder, I can no longer compile the project:

Compiling ./lnet/lib/lmimewrapper.pp
lmimewrapper.pp(255,76) Error: Incompatible type for arg no. 1: Got "TBogusStream", expected "tstream"

Here is the line 255:

meBase64 : FEncodingStream := TBase64EncodingStream.Create(FLocalStream);

If I try to compile the same unit not in MSEide but in Geany, it compiles without any error.

from mseide-msegui.

What fpc version, on what os?
I dont have any idea what is INet library.

from mseide-msegui.

but in Geany, it compiles without any error.

Huh, this one sorry I dont understand, do you use same compiler?

from mseide-msegui.

Huh, this one sorry I dont understand, do you use same compiler?

Yes, it's the same compiler, but as I call FPC from Geany (and not from MSEide), the compiler uses the original units, and not the units that we have modified and included in MSEgui. You see the problem? The lNet library uses the FPC units that we modified and included in MSEgui.

from mseide-msegui.

To save your time, here is the whole project fixed (with some parts of the code put in comment).
mse-installer-202004181804.zip
There are two projects in it (mse-installer.prj and setup.prj). Both compile and "work" (open > without crash).

@rchastain WOW.

I am totally impressed by the totally OOTB project that you have done.
I did prepare lot of coffee for a long white night and, just copy your files in original project, compile it and it works-run directly at the first time, without changing anything!

Ha you are a real MSE-guru.

Well done Roland.

And yes, there are incredible gems there in MSEuniverse.

from mseide-msegui.

@rchastain The project tools/mse-installer/setup.prj seems to me perfect as base for your idea for a installer.
I would prefer this that using InnoSetup, who is great, but Windows only.

(But maybe change the original color...)

from mseide-msegui.

the compiler uses the original units, and not the units that we have modified and included in MSEgui. You see the problem?

Not really.

Could you check with Project Option - Make - Show command line if it uses the same command than Geany?

from mseide-msegui.

Not really.

Fred, it's very simple. If I compile from MSEide, modified units are in the path. If I compile from Geany, modified units are not in the path.

from mseide-msegui.

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

from mseide-msegui.

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

from mseide-msegui.

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!

from mseide-msegui.

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

from mseide-msegui.

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.

from mseide-msegui.

I guess I have found a solution:
#11

OK, I start to test your modifications.

from mseide-msegui.

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.

from mseide-msegui.

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.

from mseide-msegui.

let say it in International English

What did we miss?

from mseide-msegui.