From: Sieghard <s_...@ar...> - 2023-09-01 22:13:22
|
Hello people here, I'm already some time now in doubt about my ability to reach the mseide- msegui mailing list. I wrote a few messages lately, and they all seemed to appear correctly on the list, but I didn't get any sign they were seen by anyone else. Although this might be because my messages weren't of interest to somebody, I had expected that at least the announcement of a new version of my "MSEclock" demo and an experimental PostgreSQL "browser" might have been recognized. So the question for me is: is the list dead, my access cut off, or can my messages still be read by the participants? In addition, I do have a problem I need help with. It pertains to the above mentioned PostgreSQL "browser", that works quite nicely for displaying the contents of a table, but which fails miserably for updates, at least when a floating point field is involved. I suspect this to arise from the way fpc (and msegui along with it) passes these fields to an application. PostgreSQL provides two distinct floating point formats (and quite a number of data types not supported by the fpc functions at all), "double precision", 64 bits wide, like fpc's "double"s, and "real", 32 bits wide, corresponding to fpc's "single" type. But fpc maps both of them to doubles, which might produce inconsistencies, perhaps even field corruption, for automatic updates (i.e. updates without an explicitly constructed SQL statement). Sadly, there seems to be no way to even get notice of the correct field size, and no method to inform the update process of it. This seems to let _every_ update attempt of a real field fail, even "double precision" ones, and subsequently, nothing seems to be updateable any more. Above that, I've not (yet?) found any way to get access to the affected record field's data, since the database functions of msegui are nearly exclusively column (field) oriented. The only place I found access to a record number at was in the SQLquery object, and this didn't seem to be very reliable. I'm stuck and deadlocked on the issue now and would appreciate any help to continue and make this project into something really useful, and not just for PostgreSQL but finally also for all the other database systems msegui supports... -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) ----------------------------------------------------------- Mit freundlichen Grüßen, S. Schicktanz ----------------------------------------------------------- |
From: Fred vS <fi...@ho...> - 2023-09-02 04:28:19
|
Hello Sieghard. >I had expected that at least the announcement of a new version of my "MSEclock" demo and an experimental PostgreSQL "browser" might have been recognized. Sorry but I did not note those new versions of MSEclock, PostgresSQL and mailing list I just went to your site and indeed there are new update for 2023. I will transfert it to mseuniverse demo. But, appart to me, did you give the address of your site ? I think you prefer not to make your site "public" so is difficult to follow your updates. I understand that you dont want to be a Github user but it would be much easir for everybody if you share your demo there. About your new demo of PostgresSQL, I have to install all the dependence for database server, I hope it will be more out-of-the-box than FireBird. Fre;D ________________________________ De : Sieghard via mseide-msegui-talk <mse...@li...> Envoyé : vendredi 1 septembre 2023 23:24 À : mse...@li... <mse...@li...> Cc : Sieghard <s_...@ar...> Objet : [MSEide-MSEgui-talk] Mailing list & mseide-db woes Hello people here, I'm already some time now in doubt about my ability to reach the mseide- msegui mailing list. I wrote a few messages lately, and they all seemed to appear correctly on the list, but I didn't get any sign they were seen by anyone else. Although this might be because my messages weren't of interest to somebody, I had expected that at least the announcement of a new version of my "MSEclock" demo and an experimental PostgreSQL "browser" might have been recognized. So the question for me is: is the list dead, my access cut off, or can my messages still be read by the participants? In addition, I do have a problem I need help with. It pertains to the above mentioned PostgreSQL "browser", that works quite nicely for displaying the contents of a table, but which fails miserably for updates, at least when a floating point field is involved. I suspect this to arise from the way fpc (and msegui along with it) passes these fields to an application. PostgreSQL provides two distinct floating point formats (and quite a number of data types not supported by the fpc functions at all), "double precision", 64 bits wide, like fpc's "double"s, and "real", 32 bits wide, corresponding to fpc's "single" type. But fpc maps both of them to doubles, which might produce inconsistencies, perhaps even field corruption, for automatic updates (i.e. updates without an explicitly constructed SQL statement). Sadly, there seems to be no way to even get notice of the correct field size, and no method to inform the update process of it. This seems to let _every_ update attempt of a real field fail, even "double precision" ones, and subsequently, nothing seems to be updateable any more. Above that, I've not (yet?) found any way to get access to the affected record field's data, since the database functions of msegui are nearly exclusively column (field) oriented. The only place I found access to a record number at was in the SQLquery object, and this didn't seem to be very reliable. I'm stuck and deadlocked on the issue now and would appreciate any help to continue and make this project into something really useful, and not just for PostgreSQL but finally also for all the other database systems msegui supports... -- (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 mse...@li... https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk |
From: Fred vS <fi...@ho...> - 2023-09-02 04:56:48
|
Re-hello Sieghard. About your problem with floating point formats, I need to jump into database-postgress, I will do asap. But it seems that the project mOMot2. that uses fpc, is very complete and they have some "workaround" for missing fpc things. When I am a few more "aware" about database, I will ask them (and also if they are interessed to help for a msegui-mORMot package). https://github.com/synopse/mORMot2 Of course, I would be good too to ask it to fpc forum (but I dont have the courage for that 🙁 ) Fre;D ________________________________ De : Sieghard via mseide-msegui-talk <mse...@li...> Envoyé : vendredi 1 septembre 2023 23:24 À : mse...@li... <mse...@li...> Cc : Sieghard <s_...@ar...> Objet : [MSEide-MSEgui-talk] Mailing list & mseide-db woes Hello people here, I'm already some time now in doubt about my ability to reach the mseide- msegui mailing list. I wrote a few messages lately, and they all seemed to appear correctly on the list, but I didn't get any sign they were seen by anyone else. Although this might be because my messages weren't of interest to somebody, I had expected that at least the announcement of a new version of my "MSEclock" demo and an experimental PostgreSQL "browser" might have been recognized. So the question for me is: is the list dead, my access cut off, or can my messages still be read by the participants? In addition, I do have a problem I need help with. It pertains to the above mentioned PostgreSQL "browser", that works quite nicely for displaying the contents of a table, but which fails miserably for updates, at least when a floating point field is involved. I suspect this to arise from the way fpc (and msegui along with it) passes these fields to an application. PostgreSQL provides two distinct floating point formats (and quite a number of data types not supported by the fpc functions at all), "double precision", 64 bits wide, like fpc's "double"s, and "real", 32 bits wide, corresponding to fpc's "single" type. But fpc maps both of them to doubles, which might produce inconsistencies, perhaps even field corruption, for automatic updates (i.e. updates without an explicitly constructed SQL statement). Sadly, there seems to be no way to even get notice of the correct field size, and no method to inform the update process of it. This seems to let _every_ update attempt of a real field fail, even "double precision" ones, and subsequently, nothing seems to be updateable any more. Above that, I've not (yet?) found any way to get access to the affected record field's data, since the database functions of msegui are nearly exclusively column (field) oriented. The only place I found access to a record number at was in the SQLquery object, and this didn't seem to be very reliable. I'm stuck and deadlocked on the issue now and would appreciate any help to continue and make this project into something really useful, and not just for PostgreSQL but finally also for all the other database systems msegui supports... -- (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 mse...@li... https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk |
From: Sieghard <s_...@ar...> - 2023-09-02 22:13:25
|
Hello Fred, you wrote on Sat, 2 Sep 2023 04:28:03 +0000: > Sorry but I did not note those new versions of MSEclock, PostgresSQL and > mailing list So indded some of my earlier messages semm to not have made it to the list. Well, after all, this former one obviously did, at last. > I just went to your site and indeed there are new update for 2023. > I will transfert it to mseuniverse demo. You should have checked it first - it uses my "newdialogs" (for placeability), and includes a slightly extended "msefontdialog" as its main feature. > But, appart to me, did you give the address of your site ? You DO have it, otherwise you wouldn't have been able to access it, don't you? Would you prefer if I made it accessible from my main site? > I think you prefer not to make your site "public" so is difficult to > follow your updates. That's why I always write a message to the list after a change. Sadly, this time these messages don't seem to have gotten through, and that's why I asked again. > I understand that you dont want to be a Github user but it would be much > easir for everybody if you share your demo there. That's not a problem - you're free to include it there, where and how ever you deem it fitting. > About your new demo of PostgresSQL, I have to install all the dependence > for database server, I hope it will be more out-of-the-box than FireBird. Don't hurry - it's by no means finished yet, just barely working by now. And I did use PostgreSQL mainly bcause that's the database system a quite important (tax) application I use requires, prompting me to use it for several other things as well. Getting it installed shouldn't be too difficult, and setting up a database should be easy as well. But getting it to know and use in full is a different thing. There are a number of - mostly trivial - tutorials, but there's also a very complete manual available from its developers. It originanted at the University of California, Berkeley, Computer Science Department <http://db.cs.berkeley.edu/papers>, where you can find some stuff about it. Sadly, I don't remenber where I got my (.pdf) manual from, maybe it was from the development site, <https://www.postgresql.org/> directly. you wrote on Sat, 2 Sep 2023 04:56:32 +0000: > About your problem with floating point formats, I need to jump into > database-postgress, I will do asap. As stated above, don't hurry. I mentioned that only, in case someone else might already have noticed the problem, taken care of it and perhaps even found a reliable solution, or work-around. It's probabely not even really relevant for a specific application that uses fields of well known data types, but as I wanted to write a "universal" browser, I have to find a way to get it going without such prior knowledge. > But it seems that the project mOMot2. that uses fpc, is very complete and > they have some "workaround" for missing fpc things. When I am a few more Thank you for the information, I will certainly study it. Just have to get its data first. > Of course, I would be good too to ask it to fpc forum (but I dont have Yes, this seems to arise from a limitation of fpc, probabely caused by the development and diversification of PostgreSQL - they might have implemented just the neccessary support to make it going mostly, while their focus probabely was more at mysql / mariadb. But, as I also wrote, I'm planning to try to port it to sqlite too, although that's quite different in its basics, i.e. "database" definition and management. And, after all, don't hurry, you got suffient other work to do. And I / we definitely don't want you to go Martin's way off the project... Have a nice time, and stay well and healthy! -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) ----------------------------------------------------------- Mit freundlichen Grüßen, S. Schicktanz ----------------------------------------------------------- |
From: Fred vS <fi...@ho...> - 2023-09-03 01:18:02
|
Hello Sieghard. I try to compile your new release of MSEClock but there are some errors: Compiling ./MSEclock.pas ... clockwork.pas(288,7) Error: identifier idents no member "onmouseevent" clockwork.pas(289,8) Error: identifier idents no member "onmouseevent" clockwork.pas(290,7) Error: identifier idents no member "onmouseevent" clockwork.pas(365,9) Error: Identifier not found "execute" clockwork.pas(375,60) Error: Incompatible type for arg no. 1: Got "tcolordialogfo", expected "tdialogform" clockwork.pas(376,20) Error: Class or Object types "tdialogform" and "tcolordialogfo" are not related clockwork.pas(377,6) Error: Identifier not found "CurrColor" clockwork.pas(378,9) Error: Identifier not found "execute" clockwork.pas(380,29) Error: Identifier not found "CurrColor" clockwork.pas(381,29) Error: Identifier not found "CurrColor" clockwork.pas(391,60) Error: Incompatible type for arg no. 1: Got "tcolordialogfo", expected "tdialogform" clockwork.pas(392,20) Error: Class or Object types "tdialogform" and "tcolordialogfo" are not related clockwork.pas(393,6) Error: Identifier not found "CurrColor" clockwork.pas(394,9) Error: Identifier not found "execute" clockwork.pas(394,43) Error: Identifier not found "CurrColor" clockwork.pas(507,9) Error: Identifier not found "execute" clockwork.pas(540,9) Error: Identifier not found "execute" clockwork.pas(563,9) Error: Identifier not found "execute" clockwork.pas(587,9) Error: Identifier not found "execute" clockwork.pas(738,21) Error: identifier idents no member "Execute" clockwork.pas(759,19) Error: Identifier not found "showatmouse" clockwork.pas(760,8) Error: Identifier not found "execute" clockwork.pas(771,20) Error: Identifier not found "showatmouse" clockwork.pas(772,8) Error: Identifier not found "execute" clockwork.pas(981) Fatal: There were 24 errors compiling module, stopping Fatal: Compilation aborted ________________________________ De : Sieghard via mseide-msegui-talk <mse...@li...> Envoyé : samedi 2 septembre 2023 23:13 À : mse...@li... <mse...@li...> Cc : Sieghard <s_...@ar...> Objet : Re: [MSEide-MSEgui-talk] Mailing list & mseide-db woes Hello Fred, you wrote on Sat, 2 Sep 2023 04:28:03 +0000: > Sorry but I did not note those new versions of MSEclock, PostgresSQL and > mailing list So indded some of my earlier messages semm to not have made it to the list. Well, after all, this former one obviously did, at last. > I just went to your site and indeed there are new update for 2023. > I will transfert it to mseuniverse demo. You should have checked it first - it uses my "newdialogs" (for placeability), and includes a slightly extended "msefontdialog" as its main feature. > But, appart to me, did you give the address of your site ? You DO have it, otherwise you wouldn't have been able to access it, don't you? Would you prefer if I made it accessible from my main site? > I think you prefer not to make your site "public" so is difficult to > follow your updates. That's why I always write a message to the list after a change. Sadly, this time these messages don't seem to have gotten through, and that's why I asked again. > I understand that you dont want to be a Github user but it would be much > easir for everybody if you share your demo there. That's not a problem - you're free to include it there, where and how ever you deem it fitting. > About your new demo of PostgresSQL, I have to install all the dependence > for database server, I hope it will be more out-of-the-box than FireBird. Don't hurry - it's by no means finished yet, just barely working by now. And I did use PostgreSQL mainly bcause that's the database system a quite important (tax) application I use requires, prompting me to use it for several other things as well. Getting it installed shouldn't be too difficult, and setting up a database should be easy as well. But getting it to know and use in full is a different thing. There are a number of - mostly trivial - tutorials, but there's also a very complete manual available from its developers. It originanted at the University of California, Berkeley, Computer Science Department <http://db.cs.berkeley.edu/papers>, where you can find some stuff about it. Sadly, I don't remenber where I got my (.pdf) manual from, maybe it was from the development site, <https://www.postgresql.org/> directly. you wrote on Sat, 2 Sep 2023 04:56:32 +0000: > About your problem with floating point formats, I need to jump into > database-postgress, I will do asap. As stated above, don't hurry. I mentioned that only, in case someone else might already have noticed the problem, taken care of it and perhaps even found a reliable solution, or work-around. It's probabely not even really relevant for a specific application that uses fields of well known data types, but as I wanted to write a "universal" browser, I have to find a way to get it going without such prior knowledge. > But it seems that the project mOMot2. that uses fpc, is very complete and > they have some "workaround" for missing fpc things. When I am a few more Thank you for the information, I will certainly study it. Just have to get its data first. > Of course, I would be good too to ask it to fpc forum (but I dont have Yes, this seems to arise from a limitation of fpc, probabely caused by the development and diversification of PostgreSQL - they might have implemented just the neccessary support to make it going mostly, while their focus probabely was more at mysql / mariadb. But, as I also wrote, I'm planning to try to port it to sqlite too, although that's quite different in its basics, i.e. "database" definition and management. And, after all, don't hurry, you got suffient other work to do. And I / we definitely don't want you to go Martin's way off the project... Have a nice time, and stay well and healthy! -- (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 mse...@li... https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk |
From: Sieghard <s_...@ar...> - 2023-09-06 22:13:27
|
Hello vasi, you wrote on Wed, 6 Sep 2023 13:29:49 +0300: > https://www.bu.edu/csmet/files/2021/03/Getting-Started-with-SQLite.pdf > https://www.pearsonhighered.com/assets/samplechapter/0/6/7/2/067232685X.pdf > https://kshmirko.github.io/static/sqlite_tutorial.pdf Thank you for the links, that will save me quite some time researching for the literature. (As the weather here is very sunny and fair right now, there's a lot of work to do outside, and then, there's something unpleasant lurking in the back, too: the yearly tax declaration...) -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) ----------------------------------------------------------- Mit freundlichen Grüßen, S. Schicktanz ----------------------------------------------------------- |
From: Sieghard <s_...@ar...> - 2023-09-06 23:43:21
|
Hello Fred, you wrote on Wed, 6 Sep 2023 14:30:58 +0000: > > Be warned - it uses the special dialog form from my "newdialogs". > > Yes, of course I used it 😉 ! Ok, then everything should work now. > Now there is a other challenge, makes your msefontdialog a widget for > mseide. > For this it needs to create a tfondialog class with a "controler" like > used for tfiledialog". To register the "tfontdialog" component as No, why should that be neccessary? I don't even see a need for the "controller" in the file dialog, that, in my opinion, just serves to (over) complicate the thing, and quite some others, too. Probabely Martin meant to consolidate many dialog functions using such a construct, but to me, it looks a lot like he went off track with that. > But for the controler, for the test it was only a dummy controler. > And to do a working controler it is a other story, but sure you will do Only if you show me a compelling reason to do so. As it is, the dialog does what it was designed for, and it has more features than any of the standard dialogs of mseide. Specifically, it is fully relocatable and placeable. Try that with any of the original dialogs. There, the "controller" is just needed because they are nailed down to their design parameters, to break up this fixture and allow for some external control through the back door, so to speak. I dislike such snaky proceeding. With all due respect for Martin's huge and impressive work, one must still see that this was - is - the work of a single person. Which impies that it WILL have its limitations, even flaws and detours. I DO consider the original dialogs to be mostly examples of such. (Mind you, not ALL of them do have their own "controller"! And there ARE objects incorporating useful controllers, too.) Bur anyway, don't mind, have a good time and success! -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) ----------------------------------------------------------- Mit freundlichen Grüßen, S. Schicktanz ----------------------------------------------------------- |
From: Fred vS <fi...@ho...> - 2023-09-06 23:53:27
|
Hello Sieghard. >> For this it needs to create a tfondialog class with a "controler" like >> used for tfiledialog". To register the "tfontdialog" component as > No, why should that be neccessary? I was talking about a widget that can be edited by the GUI Object Inspector. But I agree with you, it is not really needed for the fontdialog, it is more needed for visual component like pannels, stringedit, etc... So ok, sorry for the noise. And many thanks for your great work. Fred. ________________________________ De : Sieghard via mseide-msegui-talk <mse...@li...> Envoyé : jeudi 7 septembre 2023 00:46 À : mse...@li... <mse...@li...> Cc : Sieghard <s_...@ar...> Objet : Re: [MSEide-MSEgui-talk] Mailing list & mseide-db woes Hello Fred, you wrote on Wed, 6 Sep 2023 14:30:58 +0000: > > Be warned - it uses the special dialog form from my "newdialogs". > > Yes, of course I used it 😉 ! Ok, then everything should work now. > Now there is a other challenge, makes your msefontdialog a widget for > mseide. > For this it needs to create a tfondialog class with a "controler" like > used for tfiledialog". To register the "tfontdialog" component as No, why should that be neccessary? I don't even see a need for the "controller" in the file dialog, that, in my opinion, just serves to (over) complicate the thing, and quite some others, too. Probabely Martin meant to consolidate many dialog functions using such a construct, but to me, it looks a lot like he went off track with that. > But for the controler, for the test it was only a dummy controler. > And to do a working controler it is a other story, but sure you will do Only if you show me a compelling reason to do so. As it is, the dialog does what it was designed for, and it has more features than any of the standard dialogs of mseide. Specifically, it is fully relocatable and placeable. Try that with any of the original dialogs. There, the "controller" is just needed because they are nailed down to their design parameters, to break up this fixture and allow for some external control through the back door, so to speak. I dislike such snaky proceeding. With all due respect for Martin's huge and impressive work, one must still see that this was - is - the work of a single person. Which impies that it WILL have its limitations, even flaws and detours. I DO consider the original dialogs to be mostly examples of such. (Mind you, not ALL of them do have their own "controller"! And there ARE objects incorporating useful controllers, too.) Bur anyway, don't mind, have a good time and success! -- (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 mse...@li... https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk |
From: Sieghard <s_...@ar...> - 2023-09-08 22:13:22
|
Hello Fred, you wrote on Fri, 8 Sep 2023 17:40:39 +0000: > Ooops, sorry, I read too fast and did not see it (and did not know that > option). Welll... Anyway, when you grow older, you'll probabely get more tempered. (I think...😉 [stealing your smiley]) > Yep, enabled in the stat option sfo_createpath := true makes the trick > (and the directory 😉 ). Yes. And it might not be a bad idea to make that automatic, but I have yet to find out how that can be done - must have something to do with a "state" set and some "designing" value. ... > But for the project mseclock, I wait for your green light. Here I must ask: WHAT "project" - MSEclock contains all the files neccessary to build it along with the "newdialogs" used? And, WHAT "green light"? I stated I gave you per mission to use it to your desire (as long as you or anyone else won't bother me for any effect of it), so it's impossible to give a "greener" light. -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) ----------------------------------------------------------- Mit freundlichen Grüßen, S. Schicktanz ----------------------------------------------------------- |
From: Fred vS <fi...@ho...> - 2023-09-08 22:43:22
|
Hello Sieghard. >WHAT "green light"? Did you try mseclock and all the "newdialogs" already on Windows too ? 😉 I prefer not to hurt you if I find something to change, so I let you with the commands. 😉 😉 Fre;D |
From: Sieghard <s_...@ar...> - 2023-09-09 00:13:24
|
Hello Fred, you wrote on Fri, 8 Sep 2023 17:40:39 +0000: [Re: The stat file mechanism] I did some playing around with this to explore the actions and effects provoked by specifying "unusual" parameters, specifically for the "filedir" and "filename" parameters. Doing so, I realized that the "filedir" parameter isn't merely a single directory specification, but an array of such, akin to the "PATH" environment variable. Unfortunately, this can provoke some unexpected effects, especially in conjunction with Linux' (Unix') "HOME" directory designator, '~'. Thus, I inserted a preprocessing step to the "path" handling that replaces a leading '~' character with the HOME directory specification. This also works if just a single directory is given there. And I also made provision to the case that a directory specification does NOT end in a slash by adding one in that case. I append the resulting code to this message directly, because the modification is rather localized and does only pertain to the procedure named "tstatfile.writestat". As another point, I ALSO included a suggestion for a minor extension of this procedure, to allow for an empty filename to effect the use of the (base) name of the executable program, rather than to silently ignore the stat write request, as it does now. This is just a suggestion, and might be considered unneccessary, or it might be made optional by extending the set of option values by something like "sfo_useexename". This is the modified procedure: ---------------------------------------------------- procedure tstatfile.writestat(const stream: ttextstream = nil); var stream1: ttextstream; ar1: filenamearty; // fname1: filenamety; ///////////////////////////////////////////// i: integer; ///////////////////////////////////////////// bo1: boolean; begin if assigned(fonstatbeforewrite) then begin fonstatbeforewrite(self); end; if fnext <> nil then begin fnext.writestat(nil); end; stream1:= stream; ///////////////////////////////////////////// // Suggestion: if no filename specified, use executable base name - ??? // - optionally do so only if a NEWLY DEFINED option ("sfo_useexename" // or so) is set // - presumes fixed extension of "ConfExt = '.sta';" or such // -code: // IF (stream1 = nil) AND // not a memory stat file ?? // (fFileName = '') // use program name as a "last ressort" // THEN fFileName:= ExtractFilename (Argv [0])+ ConfExt; ///////////////////////////////////////////// if (stream1 = nil) and (filename <> '') then begin if sfo_memory in foptions then begin stream1:= memorystatstreams.open(ffilename,fm_create); end else begin if floadedfile = '' then begin unquotefilename(ffiledir,ar1); ///////////////////////////////////////////// FOR i:= 0 TO high (ar1) DO BEGIN {$IFDEF linux OR defined (freebsd) or defined (netbsd) OR defined openbsd() OR defined (Solaris)} // Or whatever is needed here... // On Linux, resolve tilde character and replace with home directory IF ar1 [i][1] = '~' THEN ar1 [i]:= GetEnvironmentVariable ('HOME')+ Copy (ar1 [i], 2, Length (ar1 [i])); {$ENDIF} // No directory separator after directory name? IF ar1 [i][Length (ar1 [i])] <> DirectorySeparator THEN ar1 [i]:= ar1 [i]+ DirectorySeparator; END; ///////////////////////////////////////////// if not findfile(ffilename,ar1,floadedfile) then begin floadedfile:= defaultfile(ar1); end; if (sfo_createpath in foptions) and not findfile(floadedfile) then begin createdirpath(msefileutils.filedir(floadedfile)); end; end; try if sfo_transaction in foptions then begin stream1:= ttextstream.createtransaction(floadedfile); end else begin stream1:= ttextstream.Create(floadedfile,fm_create); end; except floadedfile:= ''; raise; end; end; // stream1.encoding:= fencoding; end; if stream1 = nil then begin exit; end; try if (fcryptohandler <> nil) then begin stream1.cryptohandler:= fcryptohandler; end; awriter:= tstatwriter.create(stream1,fencoding); updateoptions(awriter); bo1:= false; try if (stream1.handle <> invalidfilehandle) and not stream1.usewritebuffer then begin bo1:= true; stream1.usewritebuffer:= true; end; internalwritestat; // if assigned(fonstatafterwrite) then begin // fonstatafterwrite(self); // end; finally freeandnil(awriter); if bo1 then begin stream1.usewritebuffer:= false; end; end; finally if stream = nil then begin stream1.Free; end else begin if (fcryptohandler <> nil) then begin stream1.cryptohandler:= nil; end; end; end; if assigned(fonstatafterwrite) then begin fonstatafterwrite(self); end; end; ---------------------------------------------------- Thank you for your consideration, and keep up the good work! -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) ----------------------------------------------------------- Mit freundlichen Grüßen, S. Schicktanz ----------------------------------------------------------- |
From: Sieghard <s_...@ar...> - 2023-09-09 12:13:24
|
Hello Fred, you wrote on Fri, 8 Sep 2023 17:40:39 +0000: [Re: The stat file mechanism] So here is another follow up message, this time pertaining to the previously presented amendment to the stat file mecahnism, unit file "kernel/statfile.pas". I was a bit overly eager to get this working for writing a stat file, when no path formerly existed. This does indeed work with the listing of the "tstatfile.writestat" routine I had included. BUT - of course, after it was created successfully, the stat file ought to be successfully reopened and evaluated on a succeeding invocation of the program - and that's a point where most of the same measures as for writing had to take effect. So another, equivalent, modification has to included. So, to avoid too much code duplication, I put the required statements in a separate procedure that is called in the "writestat" and as well in the "readstat" method at the appropriate place. Using this, it's possible to simply use the common "~" HOME designator on Linux and the bsds (if that can be used there at all, if not the conditional had to be adapted) and to specify a path without a trailing separator character, as otherwise the path gets directly merged with the file name, leading to some unwieldy nameing "effects". I just provide the "diff" output here, performing a (probabely inverted) patch should produce the modified version of the unit file for testing: ---------------------------------------------------- 107,109d106 < ///////////////////////////////////////////// < PROCEDURE completepath (ar1: filenamearty); < ///////////////////////////////////////////// 455,474d451 < ///////////////////////////////////////////// < PROCEDURE tstatfile.completepath (ar1: filenamearty); < VAR < i: integer; < BEGIN < FOR i:= 0 TO high (ar1) DO BEGIN < {$IFDEF linux OR defined (freebsd) or defined (netbsd) OR < defined (openbsd) OR defined (Solaris)} < // On Linux, resolve tilde character and replace with home directory < IF ar1 [i][1] = '~' < THEN ar1 [i]:= GetEnvironmentVariable ('HOME')+ < Copy (ar1 [i], 2, Length (ar1 [i])); < {$ENDIF} < // No directory separator after directory name? < IF ar1 [i][Length (ar1 [i])] <> DirectorySeparator < THEN ar1 [i]:= ar1 [i]+ DirectorySeparator; < END; < END; < ///////////////////////////////////////////// < 498,500d474 < ///////////////////////////////////////////// < completepath (ar1); < ///////////////////////////////////////////// 632,634d605 < ///////////////////////////////////////////// < completepath (ar1); < ///////////////////////////////////////////// ---------------------------------------------------- I hope you find this (somwhat) useful, and Thank you again for your kind consideration. Keep up the good work! -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) ----------------------------------------------------------- Mit freundlichen Grüßen, S. Schicktanz ----------------------------------------------------------- |
From: Sieghard <s_...@ar...> - 2023-09-09 12:15:14
|
Hello Fred, you wrote on Fri, 8 Sep 2023 17:40:39 +0000: [Re: The stat file mechanism] And not to forget about the suggestion pertaining to the filename parameter of a stat file, I still think it might be useful to have the option to let the mechanism create the name according to the executable's name, especially if that might be renamed: It required the following modifications: /// At the beginning of the unit file, /// at the location give by the preceding snippet: statfileoptionty = (sfo_memory,sfo_deletememorydata, //delete after read sfo_createpath, ////////////////////////// sfo_useexename, ////////////////////////// /// and const ////////////////////////// ConfExt = '.sta'; ////////////////////////// /// And in the body of the procedure tstatfile.readstat: stream1:= stream; ///////////////////////////////////////////// // Suggestion: if no filename specified, use executable base name - ??? // - optionally do so only if a NEWLY DEFINED option ("sfo_useexename" // or so) is set // - presumes fixed extension of "ConfExt = '.sta';" or such // -code: IF (sfo_useexename in foptions) AND (NOT (sfo_memory in foptions)) AND (stream1 = nil) AND // not a memory stat file ?? (fFileName = '') // use program name as a "last ressort" THEN fFileName:= ExtractFilename (Argv [0])+ ConfExt; ///////////////////////////////////////////// This will set the filename to the "calling" name of the executable, i.e. the name it was started with. This CAN be different on Unixen that know soft links, since this will be the soft link name, not the name of the thus referenced file itself. (As hard links cannot be recognized, these will always result in a stat file name of the real executable name.) If you this might be of use, you can include it in the library unit. I can provide additional information if you require. Thak you for your consideration, success! -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) ----------------------------------------------------------- Mit freundlichen Grüßen, S. Schicktanz ----------------------------------------------------------- |
From: Fred vS <fi...@ho...> - 2023-09-12 22:09:59
|
Hello Sieghard. >statfileoptionty = (sfo_memory,sfo_deletememorydata, //delete after read > sfo_createpath, ////////////////////////// > sfo_useexename, ////////////////////////// Yes, good idea! But if we add a element in statfileoptionty, mseide should be recompiled to see the option in the Object Inspector. |
From: Sieghard <s_...@ar...> - 2023-09-28 20:13:20
|
Hello Fred, you wrote on Thu, 28 Sep 2023 00:46:40 +0000: > How, you did a lot of work, thanks! All things to amend insuffiencies I didn't want to perpetuate. > I am hyper busy this week but sure I will jump into it this week-end. Don't hurry, do your tasks thoroughly to make them last and not come back on you. Have good time, success! -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) ----------------------------------------------------------- Mit freundlichen Grüßen, S. Schicktanz ----------------------------------------------------------- |
From: mohamed h. <me...@ho...> - 2023-09-29 16:01:22
|
The remarks I sent are not emergencies but lines to be added to TODO list. Med ________________________________ De : Sieghard via mseide-msegui-talk <mse...@li...> Envoyé : jeudi 28 septembre 2023 19:45 À : mse...@li... <mse...@li...> Cc : Sieghard <s_...@ar...> Objet : Re: [MSEide-MSEgui-talk] Mailing list & mseide-db woes Hello Fred, you wrote on Thu, 28 Sep 2023 00:46:40 +0000: > How, you did a lot of work, thanks! All things to amend insuffiencies I didn't want to perpetuate. > I am hyper busy this week but sure I will jump into it this week-end. Don't hurry, do your tasks thoroughly to make them last and not come back on you. Have good time, success! -- (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 mse...@li... https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk |
From: Fred vS <fi...@ho...> - 2023-09-29 16:26:31
|
Hello Med. >The remarks I sent are not emergencies but lines to be added to TODO list. Yes but for the "Inherited" forms in menu create-forms it was a big bug in MSEide And it was also in ideU. The most strange is that bug was there for many years and nobody noted it. So better not to add it in TODO list and fix it now (it was fixed last night) Fre;D |
From: Sieghard <s_...@ar...> - 2023-09-03 21:37:21
|
Hello Fred, you wrote on Sun, 3 Sep 2023 01:17:44 +0000: > I try to compile your new release of MSEClock but there are some errors: > > Compiling ./MSEclock.pas > ... > clockwork.pas(288,7) Error: identifier idents no member "onmouseevent" Yes. This is due to an addition you had suggested a couple subversions ago and not yet instituted: at line 985 in file "msewidgets.pas" // property onmouseevent; // should we not enable it ? I did. > clockwork.pas(365,9) Error: Identifier not found "execute" > clockwork.pas(375,60) Error: Incompatible type for arg no. 1: Got > "tcolordialogfo", expected "tdialogform" clockwork.pas(376,20) Error: I DID state that this version ALSO uses my previously presented "newdialogs". Don't you have them anymore? Then I should upload them anew. There's a completely new dialog included for font selection akin to the kind most applications under X do provide now. It was already there with the previous version of MSEclock (that also requred the "newdialogs"), but is now extended to (as far as I can see) full control of font properties. And I DO suggest the "newdialogs" for consideration for inclusion into msegui, if "only" because I hate dialogs that are nailed on an arbitrary position on the screen. All of your errors except the first one DO arise from this omission. Should I upload the "newdialogs" directory another time? BTW, there's another new dialog, "replacedialogform.pas" (which is really a search or replace dialog), that doesn't have a corresponding implementation among msegui's dialogs. It's included for your examination and for possible inclusion (probabely renamed) into msegui's stock of dialogs. And, in addition, in the meantime I found a - clunky-clumsy - work-around for the posting problem in the database browser application. And I renamed it, because "PSQLcat" doesn't seem a fitting name after all. It's called "PSQLbrowse" now, and all its functions seem to work correctly, as far as I was able to test them. Be warned though: this does ALSO usee my "newdialogs"! BTW, in conjunction with my playing around with this application, I found a problem, if not omission or even error, in the msegui database functions. The issue is that closing a database does NOT correctly, i.e. completely, de-initialize the datasource. Specifically, it does not discard the field data structure built-up for the formerly open database, and on opening another one that has a different field structure it fails, trying to access the old fields again. This is a basic problem, as it originates from the "mdb.pas" unit in the "fpccompatibility" directory. I did not try to tinker with that, but includedd an explicit de-initialization statment, "SQLquery.Fields.Clear;" in my application, although I believe that it does by no means belong there. It took my quite some time to figure out why opening a different table did always fail after any modification of a value in a previously opened table. Although this will not hamper an application only dealing with only one table per data source, it DID bite me for accessing different tables using just one over again. Well, problem solved - but should that be kept so, or was this a candidate for an amendment of the library function? -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) ----------------------------------------------------------- Mit freundlichen Grüßen, S. Schicktanz ----------------------------------------------------------- |
From: Fred vS <fi...@ho...> - 2023-09-04 14:14:12
|
Hello Sieghard. >> clockwork.pas(365,9) Error: Identifier not found "execute" >> clockwork.pas(375,60) Error: Incompatible type for arg no. 1: Got >> "tcolordialogfo", expected "tdialogform" clockwork.pas(376,20) Error: > I DID state that this version ALSO uses my previously presented "newdialogs". No, I dont have those previous version, like I already explained, I have a new computer without saved-backup. Please, Bitte, por favor, if you dont use the "official" last release of MSEgui https://github.com/mse-org/mseide-msegui/releases or some modified units, copy those modified units in the root directory of your project. Then all will be much more easy. Thanks. Fred. ________________________________ De : Sieghard via mseide-msegui-talk <mse...@li...> Envoyé : dimanche 3 septembre 2023 23:26 À : mse...@li... <mse...@li...> Cc : Sieghard <s_...@ar...> Objet : Re: [MSEide-MSEgui-talk] Mailing list & mseide-db woes Hello Fred, you wrote on Sun, 3 Sep 2023 01:17:44 +0000: > I try to compile your new release of MSEClock but there are some errors: > > Compiling ./MSEclock.pas > ... > clockwork.pas(288,7) Error: identifier idents no member "onmouseevent" Yes. This is due to an addition you had suggested a couple subversions ago and not yet instituted: at line 985 in file "msewidgets.pas" // property onmouseevent; // should we not enable it ? I did. > clockwork.pas(365,9) Error: Identifier not found "execute" > clockwork.pas(375,60) Error: Incompatible type for arg no. 1: Got > "tcolordialogfo", expected "tdialogform" clockwork.pas(376,20) Error: I DID state that this version ALSO uses my previously presented "newdialogs". Don't you have them anymore? Then I should upload them anew. There's a completely new dialog included for font selection akin to the kind most applications under X do provide now. It was already there with the previous version of MSEclock (that also requred the "newdialogs"), but is now extended to (as far as I can see) full control of font properties. And I DO suggest the "newdialogs" for consideration for inclusion into msegui, if "only" because I hate dialogs that are nailed on an arbitrary position on the screen. All of your errors except the first one DO arise from this omission. Should I upload the "newdialogs" directory another time? BTW, there's another new dialog, "replacedialogform.pas" (which is really a search or replace dialog), that doesn't have a corresponding implementation among msegui's dialogs. It's included for your examination and for possible inclusion (probabely renamed) into msegui's stock of dialogs. And, in addition, in the meantime I found a - clunky-clumsy - work-around for the posting problem in the database browser application. And I renamed it, because "PSQLcat" doesn't seem a fitting name after all. It's called "PSQLbrowse" now, and all its functions seem to work correctly, as far as I was able to test them. Be warned though: this does ALSO usee my "newdialogs"! BTW, in conjunction with my playing around with this application, I found a problem, if not omission or even error, in the msegui database functions. The issue is that closing a database does NOT correctly, i.e. completely, de-initialize the datasource. Specifically, it does not discard the field data structure built-up for the formerly open database, and on opening another one that has a different field structure it fails, trying to access the old fields again. This is a basic problem, as it originates from the "mdb.pas" unit in the "fpccompatibility" directory. I did not try to tinker with that, but includedd an explicit de-initialization statment, "SQLquery.Fields.Clear;" in my application, although I believe that it does by no means belong there. It took my quite some time to figure out why opening a different table did always fail after any modification of a value in a previously opened table. Although this will not hamper an application only dealing with only one table per data source, it DID bite me for accessing different tables using just one over again. Well, problem solved - but should that be kept so, or was this a candidate for an amendment of the library function? -- (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 mse...@li... https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk |
From: Sieghard <s_...@ar...> - 2023-09-06 23:45:15
|
Hello Fred, you wrote on Wed, 6 Sep 2023 13:31:22 +0000: > Indeed, when creating "~/.msetools" , no more errors. > But, humm, what do you think about: > -First check if the directory exists, if no create it. I didn't care because that was introduced, after quite some discussion, a long time ago by Martin himself. > -Or why not use the "~/.config" directory that is provided (normally) in > each Linux distro? This was discussed as well, and dismissed, because that is not neccessarily reliably available. It's more a GUI dependent facility, used by gtk and gnome or such. I do realize that it's quite common nowadays, but wasn't even when this was discussed. And, BTW, there's the IDE settings directory, ~/.mseide, which "always existed", on the same level. So, as of this olden lore, I didn't even suspect that the directory might not exist if any msegui application was run on this machine before... > ( I am ok to use "~/.msetools" but then check first if it exists, if no, Well, after all, this IS a valid point I just overlooked (as explained above). It might even be sensible to just create it if it not there, as the home directory is _meant_ to be a "dumping" area for this kind of (private) data (just like "/etc" is for system wide settings). I shall include it in my applications. But I want to suggest to make that a library standard, implemented in some part of the "statfile" mechanism. What do you think? you wrote on Wed, 6 Sep 2023 13:53:26 +0000: > Sorry if 3x same mail but 2 previous do not appear, maybe too big because > of included previous mails. Well, I got it just twice. > New try without previous mai includedl: That's nice, reducing the littering of your correspondent's mail archives quite a bit, and also limiting band width and energy consumption, although just a tiny bit, especially compared to all that sense- and useless spam trash. PLEASE continue your correspondence in this same manner! Thank you a lot. -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) ----------------------------------------------------------- Mit freundlichen Grüßen, S. Schicktanz ----------------------------------------------------------- |
From: Fred vS <fi...@ho...> - 2023-09-07 00:00:36
|
Hello Sieghard. > But I want to suggest to make that a library standard, implemented in some part of the "statfile" mechanism. What do you think? Yes, the statfile mechanism is problematic sometime. For example. in NetBSD the "~" like in "~/.config" is not recognized as "root directory of user" but as a normal character. And using the /etc directory is not optimal too because it needs root access. Fred. (without copy of previous post, sorry I forgot to do it in previous mail) |
From: Sieghard <s_...@ar...> - 2023-09-07 22:15:12
|
Hello Fred, you wrote on Wed, 6 Sep 2023 23:53:13 +0000: > >> used for tfiledialog". To register the "tfontdialog" component as > > > No, why should that be neccessary? > > I was talking about a widget that can be edited by the GUI Object > Inspector. You could create something like a "calling shell" that can be parametrized with the "personalization" data, and retrieves the results. But that's certainly not a "controller" of that kind. The dialog itself is a self-contained subform. > But I agree with you, it is not really needed for the fontdialog, it is I'd even question the need for a few other dialogs, particularly the _file_ dialog. Perhaps the plan was to have an input-edit-like widget for quick file specifications - did you ever use or want to use such a thing? Yes, there are some uses for something like that, but just "firing up" a full fledged file dialog and processing its eventual result isn't much more effort, and most applications I know even just use the system file manger as such a "dialog". Even Windows does. Other examples for such things are the color dialog, the popup calendar or the memo dialog. Only the family of drop-down components has a valid use for the controller concept, IMHO. > more needed for visual component like pannels, stringedit, etc... A string edit doesn't need a controller - it's a component for building a dialog, and maybe a "controller". This also applies to all the -enter "dialogs", they're mere components for building dialogs. And, BTW, if you look at the "dialog" section of the component palette, the only _real_ dialog found there ist the file dialog. All the rest are mere - but nonetheless neccessary - building blocks for dialog forms. BTW, the color dialog doesn't even appear on the component palette. > So ok, sorry for the noise. No, THIS kind of noise is neccessary - this is a quite basic issue, and has to be discussed thoroughly to be resolved right. After all, I may be wrong with my opinion as I'm just judging from my needs and preferences. Others might have a quite different view of this issue, and might want it handled differently. This should be discussed and decided unanimously. Thank you for all your effort and cooperation, and have a good time! -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) ----------------------------------------------------------- Mit freundlichen Grüßen, S. Schicktanz ----------------------------------------------------------- |
From: Sieghard <s_...@ar...> - 2023-09-09 11:13:27
|
Hello Fred, you wrote on Fri, 8 Sep 2023 22:42:59 +0000: > >WHAT "green light"? > > Did you try mseclock and all the "newdialogs" already on Windows too ? 😉 No, because of the lack of a really working, even current, Windows. The latest I have available (but not registered, let alone being "activated") is an olden Windows 7, and I'm not even sure whether it is 64 bit capable (probabely not). So no, I didn't try on Windows because I can't. > I prefer not to hurt you if I find something to change, so I let you with > the commands. No problem - I'd even welcome if you found something to be fixed (and perhaps a resolution for it as well), and, of course, you're free to include it in your effort. Sure, for a release, testing on every platform the software is intended for is a must. But as stated above, I could at most test it for the arm line of Linux, when I get that to work - for now, I couldn't get any msegui application even to compile because of a weird linking error, where the linker reports it couldn't find some start up object file that in fact does exist. And after all, as long as there are no system dependent functions involved (as is most probabely the case with the "newdialogs", and the "MSEclock" application except the "experimental" screen copy test routines), there's no reason why something should fail, if not because of a problem in the underlying (library) code. Isn't that the boasted claim of fpc anyway? And Lazarus adopts that directly, doesn't msegui? -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) ----------------------------------------------------------- Mit freundlichen Grüßen, S. Schicktanz ----------------------------------------------------------- |
From: Sieghard <s_...@ar...> - 2023-09-16 00:13:28
|
Hello Fred, you wrote on Tue, 12 Sep 2023 22:09:41 +0000: > >statfileoptionty = (sfo_memory,sfo_deletememorydata, //delete after read > > sfo_createpath, > ////////////////////////// > > sfo_useexename, > ////////////////////////// > > Yes, good idea! Thank you. > But if we add a element in statfileoptionty, mseide should be recompiled > to see the option in the Object Inspector. Certainly, and it had to be re-registered as well, I think. Like is done for every new version of the mseide-msegui set (or mseide stand-alone version) anyway? Or, for the full version, where the source is provided, it's to be done by everyone themselves also. On the other hand, it seems it wouldn't immediately corrupt the function of an existing installation. The only drawback was that the new option wasn't accessible without recompiling the ide, it could only introduced "by hand", i.e. programmatically. But, indeed, it's not a simple "drop-in" modification. (It's similar to the "onmouseevent" field of recent concern.) (BTW, I'm still trying to implement a generally available statefile mechanism for dialog storing positions. So far, it works only partially, because of quite a few "intric(k)acies" of statefile handling as it is done natively, and I don't want to modify this in any respect.) -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) ----------------------------------------------------------- Mit freundlichen Grüßen, S. Schicktanz ----------------------------------------------------------- |
From: Fred vS <fi...@ho...> - 2023-09-16 13:25:18
|
Hello Sieghard. >(It's similar to the "onmouseevent" field of recent concern.) Hum, when I asked to commit that, you did answer that "I would not commit it...". So I did not commit it... 😉 Med proposed also to change source in msegui-DB, so maybe we could do a "big" change, with all those extended properties and with a new MSEide version, with all the binaries. But before this, all should be deeply tested onLinux + Windows + BSD (and for Windows I dont have a Windows-machine to test at the moment). Fre;D |