Hello Sieghard. > If the unit filename > was explicitly mentioned using the in keyword, the source is taken from > the filename specified:"
I did try this but without luck, it still dont load the unit at first. But this is not important, I will continue with the "paste in same directory as the main program" way. Thanks for all. Fre;D ________________________________ De : Sieghard via mseide-msegui-talk <mseide-msegui-talk@lists.sourceforge.net> Envoyé : mercredi 26 janvier 2022 23:07 À : mseide-msegui-talk@lists.sourceforge.net <mseide-msegui-talk@lists.sourceforge.net> Cc : Sieghard <s_c_...@arcor.de> Objet : Re: [MSEide-MSEgui-talk] Hello back! Hallo Fred van Stappen, vous ecrit au Tue, 25 Jan 2022 22:59:57 +0000: > >> There are 2 initialization files: ideuli.sta and ideU.ini: ... > to re-check this and do all with the mse stat file, it is on the > "todo" list. I hope you can get at it soon... But I suspect this is not the reason for my problems to get your ide t owork for me. ... > In last version 2.8.0 it is the "dynpo" way that is used, and /lang Yes, I saw that, when I installed the package. But I still don't get it to work yet, it even doesnn't compile any more... vous ecrit au Tue, 25 Jan 2022 19:32:56 +0000: > Note that in last release of ideU ( source: > https://github.com/fredvs/ideU/archive/refs/heads/main.zip ) lot of > msegui files are changed and are so in the root directory of /src, > this to force to compile those files instead of original of > mseide-msegui. ... and I suspect this to be the cause. It might be the cause, because there are a few dialog source files that you modified, so there's a mixture of "original" (modified by me already) and "old style" files that are no longer compatible. I'll have to resolve this, well, mess first to get a clean compile. Only then I'll be able to assess it any further and be able to continue (or restart?) working on the translation. > By the way do you know if there is a way to force to use one > directory as first (apart to paste the file in root directory of > project). Sorry, I didn't need to do that yet. > I did try with the fpc "directory parameter" -Futhedirectory but it > does not seem the have a hierarchy of seeking (or I miss something). The only thing I could think of here is that your sequencing attempts did collide with the many predefined assignments in fpc's configuration file (/etc/fpc.cfg). Other than that, mainly two strategies could be used: accessing the directories in sequence, using files from the first one encountered (most likely), or using the ones from the last one (less probable). This could be complicated a lot, though, by the sequence of unit names in the "uses" clause. But fpc's documentation file "user.pdf" describes the construction of a "unit search path", a really convolved construct consisting of parts specified / specifiable in different places. The following remark might be important: "Note that unit file paths specified in a config file will be added at the end, while paths specified on the command-line are added at the beginning." So it depends on _where_ additional paths are added; if you do it on the command line (what you probabely do), they are _pre_pended to the full path list, and so may take precedence. There's a compiler switch, "-vu", that's meant to show you the resulting search path. They also give an example of how this should work: "For instance, suppose that the file foo.pp needs the unit bar. Then the command fpc -Fu.. -Fuunits foo.pp will tell the compiler to look for the unit bar in the following places: 1. In the current directory. 2. In the directory where the compiler binary is (not under LINUX). 3. In the parent directory of the current directory. 4. In the subdirectory units of the current directory 5. In the standard unit directory." But I just found this interesting phrase in fpc's documentation, too: "The compiler will look for compiled versions or source versions of all units in the uses clause in the unit search path. If the unit filename was explicitly mentioned using the in keyword, the source is taken from the filename specified:" This should give you the opportunity to exactly specify not just the (even relative) path, but also the file a unit's source resides in. The syntax is given as: "uses unita in ’..\unita.pp’;" (or as appropriate). Can this help? Finalement, vous ecrit au Tue, 25 Jan 2022 19:44:27 +0000: > Maybe, to experiment with languages, it will be simpler and easier to > work with the demo of msegui_dynpo: > > https://github.com/fredvs/msegui_dynpo/archive/refs/heads/main.zip I did already download it, and will have a look at it - after all, I'd like to use the mechanism myself as well, but I didn't find the time to even build the demo yet. As always, as soon as time allows... -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) ----------------------------------------------------------- Mit freundlichen Grüßen, S. Schicktanz ----------------------------------------------------------- _______________________________________________ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk ________________________________ De : Sieghard via mseide-msegui-talk <mseide-msegui-talk@lists.sourceforge.net> Envoyé : mercredi 26 janvier 2022 23:07 À : mseide-msegui-talk@lists.sourceforge.net <mseide-msegui-talk@lists.sourceforge.net> Cc : Sieghard <s_c_...@arcor.de> Objet : Re: [MSEide-MSEgui-talk] Hello back! Hallo Fred van Stappen, vous ecrit au Tue, 25 Jan 2022 22:59:57 +0000: > >> There are 2 initialization files: ideuli.sta and ideU.ini: ... > to re-check this and do all with the mse stat file, it is on the > "todo" list. I hope you can get at it soon... But I suspect this is not the reason for my problems to get your ide t owork for me. ... > In last version 2.8.0 it is the "dynpo" way that is used, and /lang Yes, I saw that, when I installed the package. But I still don't get it to work yet, it even doesnn't compile any more... vous ecrit au Tue, 25 Jan 2022 19:32:56 +0000: > Note that in last release of ideU ( source: > https://github.com/fredvs/ideU/archive/refs/heads/main.zip ) lot of > msegui files are changed and are so in the root directory of /src, > this to force to compile those files instead of original of > mseide-msegui. ... and I suspect this to be the cause. It might be the cause, because there are a few dialog source files that you modified, so there's a mixture of "original" (modified by me already) and "old style" files that are no longer compatible. I'll have to resolve this, well, mess first to get a clean compile. Only then I'll be able to assess it any further and be able to continue (or restart?) working on the translation. > By the way do you know if there is a way to force to use one > directory as first (apart to paste the file in root directory of > project). Sorry, I didn't need to do that yet. > I did try with the fpc "directory parameter" -Futhedirectory but it > does not seem the have a hierarchy of seeking (or I miss something). The only thing I could think of here is that your sequencing attempts did collide with the many predefined assignments in fpc's configuration file (/etc/fpc.cfg). Other than that, mainly two strategies could be used: accessing the directories in sequence, using files from the first one encountered (most likely), or using the ones from the last one (less probable). This could be complicated a lot, though, by the sequence of unit names in the "uses" clause. But fpc's documentation file "user.pdf" describes the construction of a "unit search path", a really convolved construct consisting of parts specified / specifiable in different places. The following remark might be important: "Note that unit file paths specified in a config file will be added at the end, while paths specified on the command-line are added at the beginning." So it depends on _where_ additional paths are added; if you do it on the command line (what you probabely do), they are _pre_pended to the full path list, and so may take precedence. There's a compiler switch, "-vu", that's meant to show you the resulting search path. They also give an example of how this should work: "For instance, suppose that the file foo.pp needs the unit bar. Then the command fpc -Fu.. -Fuunits foo.pp will tell the compiler to look for the unit bar in the following places: 1. In the current directory. 2. In the directory where the compiler binary is (not under LINUX). 3. In the parent directory of the current directory. 4. In the subdirectory units of the current directory 5. In the standard unit directory." But I just found this interesting phrase in fpc's documentation, too: "The compiler will look for compiled versions or source versions of all units in the uses clause in the unit search path. If the unit filename was explicitly mentioned using the in keyword, the source is taken from the filename specified:" This should give you the opportunity to exactly specify not just the (even relative) path, but also the file a unit's source resides in. The syntax is given as: "uses unita in ’..\unita.pp’;" (or as appropriate). Can this help? Finalement, vous ecrit au Tue, 25 Jan 2022 19:44:27 +0000: > Maybe, to experiment with languages, it will be simpler and easier to > work with the demo of msegui_dynpo: > > https://github.com/fredvs/msegui_dynpo/archive/refs/heads/main.zip I did already download it, and will have a look at it - after all, I'd like to use the mechanism myself as well, but I didn't find the time to even build the demo yet. As always, as soon as time allows... -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) ----------------------------------------------------------- Mit freundlichen Grüßen, S. Schicktanz ----------------------------------------------------------- _______________________________________________ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
_______________________________________________ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
