Hello Fred, vous ecrit au Fri, 10 Mar 2023 00:19:31 +0000:
> Ooops, in previous post I did not get error because I used the last > commit of msegui. > > So, without the "modeswitch" I get that error, see picture: > > https://user-images.githubusercontent.com/3421249/224190166-757b36da-6a91-47f2-9466-d52eaf63d92f.png > [https://user-images.githubusercontent.com/3421249/224190166-757b36da-6a91-47f2-9466-d52eaf63d92f.png] Ok, I can see it. Funny after all, and this should definitely NOT occur, as all the components of mseide DO include a mode setting statement to enable "objfpc" mode. But - could it be that the ide you used (I presume it was the original mseide) did try to COMPILE this file as a unit on it's own? It's named ".pas" after all, and that could have triggered such an action. It probabely doesn't occur on a normal compile, when the mode settings, as seems to be the case, are "carried over" between compiles. But the mseide (and probabely your ideU, too) might call the compiler separately for each unit file, and thus tried to compile the "FieldTypeError" unit on its own. As this does NOT contain an "objfpc" mode setting, the modes "class" and "exception" possibly weren't enabled, and thus the compiler balked out. And that's the rather certain explanation for the effect - I just tried to test this assumption, opening the project with the ide (usually I compile it without it) and EXPLICITLY adding the file "FieldTypeError.pas" to the edited files list. Then started the compile, and, after a while, it INDEED failed with the very same messages as you got. Inserting the line "{$ifdef FPC}{$mode objfpc}{$endif}" remedied this, as expected. So doing this would be the real solution. Or, another option might be to change the compile strategy built into mseide to ONLY call the compiler ONCE with the project's MAIN FILE. There's even an appropriate entry in the project file ("mainfile="), but it doesn't seem to be used. Or, is it? I didn't research this further. BTW, maybe the "Check method headers" could be responsible for this behaviour? I tried it, but this doesn't affect this effect, apparently. At least not definitively... After some playing around, the ide wasn't "willing" to compile itself without error anymore, so it's not possible to say whether this option has any effect on the problem. So inserting the above mentioned mode-setting line will be required. (BTW, during my tests, the ide suddenly kept insisting to write to some file named "/home/fred/mseide-msegui/lib/common/kernel/msegui.pas" when closing the file "FieldTypeError.pas", but when I created the directory, nothing was written. Seems to be a "side effect" of Martin's creative relativism pertaining paths in project files...) (And, BTW, I found another problem with mseide's error handling that I mean to have seen before already: on encountering an error, the ide loads the pertaining source file, even if it already IS loaded. This, in the following, can cause a number of "interesting effects", especially when you're debugging your program and try to find some specific position. I don't fully remeber what I got, but I found it neccessary to ALWAYS close a file containing an error and breakpoints simultaineously [IIRC].) Well, the "BTW"s normally won't hurt as they won't occur, perhaps except the last one. It's just that I stumbled over them, and wanted to mention what I found. And, this time I didn't upload a new version of the affected file, leaving it to you to insert the mode setting statement for another commit because of its triviality. Thank you for your report, and keep up your good work! -- (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 [email protected] https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
