Menu
▾
▴
mseide-msegui-talk
|
From: Fred vS <fi...@ho...> - 2024-02-12 22:03:37
|
Hello everybody. There is a new release 5.10.0. with binaries of MSEide and the fixes of inherited forms. Also compatible with Darwin-MacOs (via XQuartz). https://github.com/mse-org/mseide-msegui/releases/tag/5.10.0 Have lot of fun. Fre;D |
|
From: vasi v. <fu...@gm...> - 2024-02-13 10:15:40
|
Hi Fred! Thank you very much for the new version. Is there a tutorial how to for fpc-llvm-3.3.1? I mean, to get or make the compiler fpc for llvm.... On Tue, Feb 13, 2024 at 12:04 AM Fred vS <fi...@ho...> wrote: > Hello everybody. > > There is a new release 5.10.0. with binaries of MSEide and the fixes of > inherited forms. > Also compatible with Darwin-MacOs (via XQuartz). > > https://github.com/mse-org/mseide-msegui/releases/tag/5.10.0 > > > Have lot of fun. > > Fre;D > _______________________________________________ > mseide-msegui-talk mailing list > mse...@li... > https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk > -- Vasi |
|
From: Fred vS <fi...@ho...> - 2024-02-13 11:18:32
|
Hello Vasi. There is a how-to here (tested for MSEgui too): https://forum.lazarus.freepascal.org/index.php/topic,61069.msg459333.html?PHPSESSID=41sd602fpnus8p7bm621igr9j4#msg459333 Fre;D ________________________________ De : vasi vasi <fu...@gm...> Envoyé : mardi 13 février 2024 11:15 À : General list for MSEide+MSEgui <mse...@li...> Objet : Re: [MSEide-MSEgui-talk] New release 5.10.0. Hi Fred! Thank you very much for the new version. Is there a tutorial how to for fpc-llvm-3.3.1? I mean, to get or make the compiler fpc for llvm.... On Tue, Feb 13, 2024 at 12:04 AM Fred vS <fi...@ho...<mailto:fi...@ho...>> wrote: Hello everybody. There is a new release 5.10.0. with binaries of MSEide and the fixes of inherited forms. Also compatible with Darwin-MacOs (via XQuartz). https://github.com/mse-org/mseide-msegui/releases/tag/5.10.0 Have lot of fun. Fre;D _______________________________________________ mseide-msegui-talk mailing list mse...@li...<mailto:mse...@li...> https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk -- Vasi |
|
From: vasi v. <fu...@gm...> - 2024-02-13 11:52:14
|
Thank you Fred, much appreciated! On Tue, Feb 13, 2024 at 1:18 PM Fred vS <fi...@ho...> wrote: > Hello Vasi. > > There is a how-to here (tested for MSEgui too): > > https://forum.lazarus.freepascal.org/index.php/topic,61069.msg459333.html?PHPSESSID=41sd602fpnus8p7bm621igr9j4#msg459333 > > > Fre;D > ------------------------------ > *De :* vasi vasi <fu...@gm...> > *Envoyé :* mardi 13 février 2024 11:15 > *À :* General list for MSEide+MSEgui < > mse...@li...> > *Objet :* Re: [MSEide-MSEgui-talk] New release 5.10.0. > > Hi Fred! > > Thank you very much for the new version. Is there a tutorial how to for > fpc-llvm-3.3.1? I mean, to get or make the compiler fpc for llvm.... > > On Tue, Feb 13, 2024 at 12:04 AM Fred vS <fi...@ho...> wrote: > > Hello everybody. > > There is a new release 5.10.0. with binaries of MSEide and the fixes of > inherited forms. > Also compatible with Darwin-MacOs (via XQuartz). > > https://github.com/mse-org/mseide-msegui/releases/tag/5.10.0 > > > Have lot of fun. > > Fre;D > _______________________________________________ > mseide-msegui-talk mailing list > mse...@li... > https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk > > > > -- > Vasi > _______________________________________________ > mseide-msegui-talk mailing list > mse...@li... > https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk > -- Vasi |
|
From: vasi v. <fu...@gm...> - 2024-02-13 14:35:29
|
I will try your tutorial on NetBSD 10 when it comes out in final version (now is at RC4) - very curios if it will work... Now, I can make it under Devuan 4.1.1 which is Debian 11. Have you heard of Chimera Linux? It uses only llvm/clang wit musl. https://chimera-linux.org/about/#buildable-from-source On Tue, Feb 13, 2024 at 1:18 PM Fred vS <fi...@ho...> wrote: > Hello Vasi. > > There is a how-to here (tested for MSEgui too): > > https://forum.lazarus.freepascal.org/index.php/topic,61069.msg459333.html?PHPSESSID=41sd602fpnus8p7bm621igr9j4#msg459333 > > > Fre;D > ------------------------------ > *De :* vasi vasi <fu...@gm...> > *Envoyé :* mardi 13 février 2024 11:15 > *À :* General list for MSEide+MSEgui < > mse...@li...> > *Objet :* Re: [MSEide-MSEgui-talk] New release 5.10.0. > > Hi Fred! > > Thank you very much for the new version. Is there a tutorial how to for > fpc-llvm-3.3.1? I mean, to get or make the compiler fpc for llvm.... > > On Tue, Feb 13, 2024 at 12:04 AM Fred vS <fi...@ho...> wrote: > > Hello everybody. > > There is a new release 5.10.0. with binaries of MSEide and the fixes of > inherited forms. > Also compatible with Darwin-MacOs (via XQuartz). > > https://github.com/mse-org/mseide-msegui/releases/tag/5.10.0 > > > Have lot of fun. > > Fre;D > _______________________________________________ > mseide-msegui-talk mailing list > mse...@li... > https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk > > > > -- > Vasi > _______________________________________________ > mseide-msegui-talk mailing list > mse...@li... > https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk > -- Vasi |
|
From: Fred vS <fi...@ho...> - 2024-02-13 15:21:49
|
Hello Vasi. >Have you heard of Chimera Linux? No, I did not know it, interesting, I suppose some tweak should be done for mselibc but (like always with mse) doable. ________________________________ De : vasi vasi <fu...@gm...> Envoyé : mardi 13 février 2024 15:35 À : General list for MSEide+MSEgui <mse...@li...> Objet : Re: [MSEide-MSEgui-talk] New release 5.10.0. I will try your tutorial on NetBSD 10 when it comes out in final version (now is at RC4) - very curios if it will work... Now, I can make it under Devuan 4.1.1 which is Debian 11. Have you heard of Chimera Linux? It uses only llvm/clang wit musl. https://chimera-linux.org/about/#buildable-from-source On Tue, Feb 13, 2024 at 1:18 PM Fred vS <fi...@ho...<mailto:fi...@ho...>> wrote: Hello Vasi. There is a how-to here (tested for MSEgui too): https://forum.lazarus.freepascal.org/index.php/topic,61069.msg459333.html?PHPSESSID=41sd602fpnus8p7bm621igr9j4#msg459333 Fre;D ________________________________ De : vasi vasi <fu...@gm...<mailto:fu...@gm...>> Envoyé : mardi 13 février 2024 11:15 À : General list for MSEide+MSEgui <mse...@li...<mailto:mse...@li...>> Objet : Re: [MSEide-MSEgui-talk] New release 5.10.0. Hi Fred! Thank you very much for the new version. Is there a tutorial how to for fpc-llvm-3.3.1? I mean, to get or make the compiler fpc for llvm.... On Tue, Feb 13, 2024 at 12:04 AM Fred vS <fi...@ho...<mailto:fi...@ho...>> wrote: Hello everybody. There is a new release 5.10.0. with binaries of MSEide and the fixes of inherited forms. Also compatible with Darwin-MacOs (via XQuartz). https://github.com/mse-org/mseide-msegui/releases/tag/5.10.0 Have lot of fun. Fre;D _______________________________________________ mseide-msegui-talk mailing list mse...@li...<mailto:mse...@li...> https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk -- Vasi _______________________________________________ mseide-msegui-talk mailing list mse...@li...<mailto:mse...@li...> https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk -- Vasi |
|
From: Sieghard <s_...@ar...> - 2024-02-13 21:13:18
|
Hello Fred, you wrote on Mon, 12 Feb 2024 21:47:34 +0000: > There is a new release 5.10.0. with binaries of MSEide and the fixes of > inherited forms. Also compatible with Darwin-MacOs (via XQuartz). > > https://github.com/mse-org/mseide-msegui/releases/tag/5.10.0 Thank you for your - as always - good work! I'll try it out as soon as I can get it. -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) ----------------------------------------------------------- Mit freundlichen Grüßen, S. Schicktanz ----------------------------------------------------------- |
|
From: vasi v. <fu...@gm...> - 2024-02-14 05:38:02
|
Thank you Fred, making fpc-llvm under Devuan 4.1.1 succeeded! NetBSD still at RC4 so it will have to wait... On Tue, Feb 13, 2024 at 1:18 PM Fred vS <fi...@ho...> wrote: > Hello Vasi. > > There is a how-to here (tested for MSEgui too): > > https://forum.lazarus.freepascal.org/index.php/topic,61069.msg459333.html?PHPSESSID=41sd602fpnus8p7bm621igr9j4#msg459333 > > > Fre;D > ------------------------------ > *De :* vasi vasi <fu...@gm...> > *Envoyé :* mardi 13 février 2024 11:15 > *À :* General list for MSEide+MSEgui < > mse...@li...> > *Objet :* Re: [MSEide-MSEgui-talk] New release 5.10.0. > > Hi Fred! > > Thank you very much for the new version. Is there a tutorial how to for > fpc-llvm-3.3.1? I mean, to get or make the compiler fpc for llvm.... > > On Tue, Feb 13, 2024 at 12:04 AM Fred vS <fi...@ho...> wrote: > > Hello everybody. > > There is a new release 5.10.0. with binaries of MSEide and the fixes of > inherited forms. > Also compatible with Darwin-MacOs (via XQuartz). > > https://github.com/mse-org/mseide-msegui/releases/tag/5.10.0 > > > Have lot of fun. > > Fre;D > _______________________________________________ > mseide-msegui-talk mailing list > mse...@li... > https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk > > > > -- > Vasi > _______________________________________________ > mseide-msegui-talk mailing list > mse...@li... > https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk > -- Vasi |
|
From: Fred vS <fi...@ho...> - 2024-02-14 14:10:40
|
Hello Vasi. Great that you have your fpc-llvm! About NetBSD, I have installed NetBSD 10 on VMWare but it is very, very, very slow. So for compiling MSEide-NetBSD, I used the fabulous fpcupdeluxe cross-compiler. Fre;D ________________________________ De : vasi vasi <fu...@gm...> Envoyé : mercredi 14 février 2024 06:37 À : General list for MSEide+MSEgui <mse...@li...> Objet : Re: [MSEide-MSEgui-talk] New release 5.10.0. Thank you Fred, making fpc-llvm under Devuan 4.1.1 succeeded! NetBSD still at RC4 so it will have to wait... On Tue, Feb 13, 2024 at 1:18 PM Fred vS <fi...@ho...<mailto:fi...@ho...>> wrote: Hello Vasi. There is a how-to here (tested for MSEgui too): https://forum.lazarus.freepascal.org/index.php/topic,61069.msg459333.html?PHPSESSID=41sd602fpnus8p7bm621igr9j4#msg459333 Fre;D ________________________________ De : vasi vasi <fu...@gm...<mailto:fu...@gm...>> Envoyé : mardi 13 février 2024 11:15 À : General list for MSEide+MSEgui <mse...@li...<mailto:mse...@li...>> Objet : Re: [MSEide-MSEgui-talk] New release 5.10.0. Hi Fred! Thank you very much for the new version. Is there a tutorial how to for fpc-llvm-3.3.1? I mean, to get or make the compiler fpc for llvm.... On Tue, Feb 13, 2024 at 12:04 AM Fred vS <fi...@ho...<mailto:fi...@ho...>> wrote: Hello everybody. There is a new release 5.10.0. with binaries of MSEide and the fixes of inherited forms. Also compatible with Darwin-MacOs (via XQuartz). https://github.com/mse-org/mseide-msegui/releases/tag/5.10.0 Have lot of fun. Fre;D _______________________________________________ mseide-msegui-talk mailing list mse...@li...<mailto:mse...@li...> https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk -- Vasi _______________________________________________ mseide-msegui-talk mailing list mse...@li...<mailto:mse...@li...> https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk -- Vasi |
|
From: Sieghard <s_...@ar...> - 2024-03-29 23:13:24
|
Hello Fred, you wrote on Mon, 12 Feb 2024 21:47:34 +0000: Another Reply... > There is a new release 5.10.0. with binaries of MSEide and the fixes of After having downloaded the new version and synchronized it with my modifications, the next step was to get the "reference" applications to work with this version. Of course, apart from using the "newdialogs", they DID work correctly. This gave me the incetive for two other approaches: - One, trying to get the "newdialogs" to fully work again. Sadly, I've not succeeded yet. They MOSTLY work, even when shifted around, but positioning is a nightmare - there are SEVERAL positioning methods and variables, and not all of them seem to be always updated correctly. So I tried to set them all, which mostly worked, except when a window straddles the top screen border. I couldn't yet find any means to find the correct CLIENT window position, as "decorated" and client positions are always returned equal, as if there were no decoration at all. As that's clearly not necessarily true, I'm stuck with that problem, although other positions are processed correctly. I'll keep on trying... - Secondly, I decided to tackle the "problem" of some missing database data types for postgresql, namely the (date & time) "interval" and the "money" type (which, I think, ought to be mapped to the existing "currency" type). I DID succeed with that, or so it seems, as I've not tested that thoroughly enough to be certain. But as I had to completely alter the existing, though incomplete and unworkable, implementation, I'm a bit tired now and put further verification aside some. Therefore, I won't publish the modified units on my web site yet. But I will pursue these topics and provide a working implementation when I see it justified. In the meantime, I want to wish you Happy Easter holidays, 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: Fred vS <fi...@ho...> - 2024-03-29 23:31:43
|
Hello Sieghard. Happy Easter holidays for you too! Thanks for your work, I am sure it will be perfect. By the way, there is a new release 5.10.2. with mainly fixes for msetimer on Linux i386 and amd64. https://github.com/mse-org/mseide-msegui/releases/tag/5.10.2 Fre;D ________________________________ De : Sieghard via mseide-msegui-talk <mse...@li...> Envoyé : vendredi 29 mars 2024 23:17 À : mse...@li... <mse...@li...> Cc : Sieghard <s_...@ar...> Objet : Re: [MSEide-MSEgui-talk] New release 5.10.0. Hello Fred, you wrote on Mon, 12 Feb 2024 21:47:34 +0000: Another Reply... > There is a new release 5.10.0. with binaries of MSEide and the fixes of After having downloaded the new version and synchronized it with my modifications, the next step was to get the "reference" applications to work with this version. Of course, apart from using the "newdialogs", they DID work correctly. This gave me the incetive for two other approaches: - One, trying to get the "newdialogs" to fully work again. Sadly, I've not succeeded yet. They MOSTLY work, even when shifted around, but positioning is a nightmare - there are SEVERAL positioning methods and variables, and not all of them seem to be always updated correctly. So I tried to set them all, which mostly worked, except when a window straddles the top screen border. I couldn't yet find any means to find the correct CLIENT window position, as "decorated" and client positions are always returned equal, as if there were no decoration at all. As that's clearly not necessarily true, I'm stuck with that problem, although other positions are processed correctly. I'll keep on trying... - Secondly, I decided to tackle the "problem" of some missing database data types for postgresql, namely the (date & time) "interval" and the "money" type (which, I think, ought to be mapped to the existing "currency" type). I DID succeed with that, or so it seems, as I've not tested that thoroughly enough to be certain. But as I had to completely alter the existing, though incomplete and unworkable, implementation, I'm a bit tired now and put further verification aside some. Therefore, I won't publish the modified units on my web site yet. But I will pursue these topics and provide a working implementation when I see it justified. In the meantime, I want to wish you Happy Easter holidays, 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 ----------------------------------------------------------- _______________________________________________ mseide-msegui-talk mailing list mse...@li... https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk |
|
From: Sieghard <s_...@ar...> - 2024-05-01 22:13:25
|
Hello Fred, you wrote on Wed, 1 May 2024 15:58:37 +0000: > There is a new branch with the Sieghard newdialogs, statfile fixes and > extended db Thank you, Fred, for publishing all of these. I hope there will be some response and critique, allowing to improve the stuff. Indeed, there's one problem with the "newdialogs" I found, but didn't have the time and opportunity to test on other platforms but my old Linux box running the openbox window manager: Everytime one dismisses such a dialog, it also blinks the main (or maybe calling) form of the application, and sometimes it stays off altogether, only complaining about a "not decorated" problem. Investigating that, I found a "waitfordecoration" call in the "kernel/linux/mseguiintf.pas" unit which seems to be superfluous, as everything seems to work flawlessly without it, without any recognizable problems concerning window decorations. Sadly, I wasn't able yet to find anythimg relevant about the blinking issue, as it's nearly impossible to follow the intircately convoluted path of execution through the pertaining, deeply entrenched and constantly traversed, window control functions. It's literally so that after setting a breakpoint there at some interesting point, you cannot run the program normally any more. Most any action opening any smallish subwindow will ALSO use that function, triggering the breakpoint and obviating the attempted action... But the culprit has to be something in conjunction with producing the window decorations, as the dialogs work correctly with window decorations disabled. Which isn't really useful, as this hampers one of the main goals of the "newdialogs", providing free and self-controlled positioning and sizing. I'll continue to pursue the issue further, but I'm afraid that it will take ample time yet. I'll report here what I can find, and of course, when the issue was solved, may have been solved... Thank you again, and keep up the good work. I hope you could enjoy the holiday -- (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...> - 2024-05-02 22:16:29
|
Hello Fred, you wrote on Wed, 1 May 2024 21:42:39 +0000: > About newdialogs: the position of the dialogs are much better now, many > thanks for this great feature. Yes, that's the good point, it mainly works now. BUT: DON'T FORGET - I DID say, they're experimental yet! Didn't I? > But there is a problem with the tfilenameedit component that uses the new > tfiledialog. Yes, there are a couple of problems with this beast. I _suppose_ it's mainly caused by the need for using this weird controller thing, that just serves to introduce another layer of complexity and seals off the final user interface from the calling program. As I wrote in my parallel message (you might not have read it when you wrote the above mentioned), there IS a deep-lying, well, "effect" causing parent forms to be affected adversely, mainly when closing such a dialog. Debugging these things seems close to impossible, because the pertaining functions are used for most every action dealing with program execution, so breakpoints are impossible to use, and following the flow of execution wildly jumps through most of the kernel (gui) code. It might be just a little quirk in the focus handling I found; on Linux, Martin opted to always return the focus "to parent", even when there isn't even a parent window. I _suspect_ that this could be coupled to the "blinking" effect, which occurs because all the application windows seem to be destroyed and rebuilt again when a "newdialog" terminates. (But X11 error handling is implemented in a rather, err, overly optimistic manner, i.e., when an error has been found and been "resolved", the affected functions still return an "ok" result anyway.) BUT a question here - and this is a VERY important one: Does this blinking (and possibly all the other adverse effects too) also occur under Windows? If it didn't occur under Windows, I might be on the right track with the above assumptions, otherwise, the problem might even be rooted deeper still. > You may try with MSEide, compile it using your newdialogs. > Run Mseide and click on menu Settings/Configure MSEide. Yes, I did that, and I found weird behaviour myself. That's why I wrote my last message, and that's a complete no-go for freely published code. Experimental is in order, maybe there's someone who can find the cause of the problem quickly, faster than I can. But it HAS definitly to be made clear that there IS A PROBLEM (and probabely a couple more). > Maybe you could take a look? I'm about it (besides some other tasks, of course), but I'm not really optimistic to have a solution fast. BTW, the other modifications should be unaffected, i.e. the db units and the stat file extensions, which are just minor patches anyway. -- (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...> - 2024-05-02 22:44:32
|
Hello Sieghard. >BUT a question here - and this is a VERY important one: Does this blinking >(and possibly all the other adverse effects too) also occur under Windows? Yes, there are problems with Windows too. See here:https://github.com/mse-org/mseide-msegui/issues/89 Fre;D |
|
From: Fred vS <fi...@ho...> - 2024-05-02 22:55:25
|
Re-hello Sieghard. I haven't jumped into your code yet but the same crash appears when you try to free an object that hasn't been created yet. My 0,01 cent, of course. Fre;D ________________________________ De : Fred vS <fi...@ho...> Envoyé : vendredi 3 mai 2024 00:44 À : General list for MSEide+MSEgui <mse...@li...> Objet : Re: [MSEide-MSEgui-talk] New release 5.10.0. Hello Sieghard. >BUT a question here - and this is a VERY important one: Does this blinking >(and possibly all the other adverse effects too) also occur under Windows? Yes, there are problems with Windows too. See here:https://github.com/mse-org/mseide-msegui/issues/89 Fre;D |
|
From: Sieghard <s_...@ar...> - 2024-03-30 21:13:29
|
Hello Fred, you wrote on Fri, 29 Mar 2024 23:31:28 +0000: > Happy Easter holidays for you too! Thank you, and to all mseide-msegui users, too. > Thanks for your work, I am sure it will be perfect. Certainly not - I don't command a big enough machine shop to be able to ascertain everything... > By the way, there is a new release 5.10.2. with mainly fixes for msetimer > on Linux i386 and amd64. > https://github.com/mse-org/mseide-msegui/releases/tag/5.10.2 Thank you for the information, I'll get it "immediately". (I.e. I instructed my machine to fetch it on the next connection.) -- (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...> - 2024-04-07 10:13:19
|
Hello Fred, you wrote on Fri, 29 Mar 2024 23:31:28 +0000: > By the way, there is a new release 5.10.2. with mainly fixes for msetimer Got it, and works correctly, as far as I use(d) it - which means, works the same as before for me. And I proceeded at expanding the PSQLbrowser program, thereby adding the capability to process fields of the postgres' types "interval" and ""money". This required modifications to, of course, unit "mpconnection", but also an addition to "msedb", which does the required formatting. It's probabely not yet complete, as I haven't yet tested whether modifications of such fields can work. And I found a way around a road block I stumbled over in conjunction with the database program. I DID want to keep separate filter and order settings for all the tables accessed, but not have changes rewrite the status file everytime for every minor adjustment. The memory stat file mechanism seemed to be the right thing to use here, especially as I had used it - well, kind of - with the "newdialogs" already. But, to no avail - although it was kind of viable with the dialogs to preset what would be saved, this isn't possible in the database case, as there's no predefined set of tables used. Well, there IS a stat file entry written for the memory stat files, named "savedmemoryfiles", but, as I had already found in the "newdialogs" case, that is not persistent, any entry not refreshed durin a session gets lost. It took me qute some time to find a work around this problem, and found that this might even be an implementation error, as there IS a second user function for additional modifications of status data, "onstateupdate". But it runs (ran) in the same context as "onstatread" or "onbstatwrite", so being not more than a slightly more complex version of these, essentially useless. Sadly, the "savedmemoryfiles" entry gets deleted during loading the memory file data just before "onstateread" and "onstateupdate" are (were) called. This makes it impossible to set up the storage requests adfterwards, as the value is gone. I had to rearrange the calling sequence to "onstateupdate", reading the "savedmemoryfiles"' data and followed by "onstatread" to be able to gain access to the pertinent data to keep the memory files' contents and provide for their further perpetuation. I even suspect that this was the intention for that whole mechanism, but it wasn't finished, perhaps because it wasn't so urgently needed to have been impairing. Using some simple manipulation of the data accessible that way, I was able to keep an extensible list of selection data for any number of database tables, and even could simplyfy the perpetuation of dialog ancillary data quite a bit. So I'm going now to provide an intermediate version of my modifications, including the "newdialogs", though not complete yet, but working, and the modifications to the database units created up to now soon. I'll give notice when they will be available, as usual. (BTW, I hope you don't mind my lengthy ramblings about my doing - I like to think they could be useful as kind of documentation of what I did.) Have a nice 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...> - 2024-04-17 22:13:18
|
Hello Fred, this is a supplement to my previous posting here. The therein mentioned projects are mainly working now, and I've also produced a SQLite browser application similar to the Postgresql one. My "newdialogs" are mostly working as well, although there's one annoying effect left, making the main form "blink" for a moment when one is closed. I hope to get this eliminated. But I've a BIG gripe to present: At least with the current ide, debugging has evolved to a nightmare. That the debugger crashes for any minor reason, like being pointed to a dynamic array (ANY dynamic array variable, not just uninitialized ones), is a minor problem here. The real nuisance is the handling of editor files. Assume you have a unit file open and try to compile the program, but there is an error in the unit file. THis leads unconditionally to another instance of the unit file to be opened to presnt the error, AND if the unit has a form, complain that the form file CANNOT be opened correctly, instead opening it as an ordinary text file AND setting THIS as the active editor file. This is completely reproducible here. And the same procedure happens even without an error on running a program up to a breakpoint set with in an ipen editor file - it gets RELOADED a second time, and the ide complains about an unability to also load the uni's form as a form, instead presenting it as a text file. This also happens, "of course", when a real error occurs during running a program. It looks a bit like a problem with the editor's file management, which cannot recognize whether a file is already open or hust blindly tries to load any file or "unit" handed it by some other function, but alway<s trying to open a source and a form file together. That's really annoying duringdebugging, when you try to set and clear breakpoints as needed, as by doing this, you often PROVOKE such a multiple load process and the ensuing complaint from the editor, distracting you from what you wanted to achieve or observe. I DO hope that this is just affecting "me" (my system), as I'm using a not so really common variant of Linux,albeit a current one: Slackware Linux version 15 for x86_64, kernel 6.6.15 on AMD A10-9700 with RADEON R7 graphics, using plain X11 with the openbox window manager and NO "desktop environment"..The ide causing the problems wascompiled with FPC 3.2.2, but works identically when compiled with FPC 3.3.1, using msegui version 5.10.2 (although the behaviour, though not thoroughly observed, also existed already for a few of the previous versions). I hope this helps to investigate - and reproduce - the problem and it's correction. Thank you very much, and have a good time nonetheless. BTW, I'll probabely "publish" the latest project sources on my web site soon, but I'd like to correct the remaining issues first, if possible. I'll give you notice here. -- (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...> - 2024-04-18 21:26:30
|
Hello Sieghard. I apologize for the late answer. >The therein mentioned projects are mainly working now, and I've also produced a SQLite browser application similar to the Postgresql one. My "newdialogs" are mostly working as well, although there's one annoying effect left, making the main form "blink" for a moment when one is closed. Thanks for this great addition, I will test it deeply asap. >But I've a BIG gripe to present: At least with the current ide, debugging has evolved to a nightmare. I am sorry but I cannot reproduce (or understand) the problem. Could you, please, test your project with the latest mseide from Martin: https://sourceforge.net/projects/mseide-msegui/files/mseide-msegui/4.6.2/ Was the problem already there? If debugging with mseide version 4.6.2 is ok, we need to find from which mseide version 5.x.x the problem appeared. Could you do a test project, with some break-points defined, and explain step-by-step how to get the problems? Fred. ________________________________ De : Sieghard via mseide-msegui-talk <mse...@li...> Envoyé : mercredi 17 avril 2024 22:31 À : mse...@li... <mse...@li...> Cc : Sieghard <s_...@ar...> Objet : Re: [MSEide-MSEgui-talk] New release 5.10.0. Hello Fred, this is a supplement to my previous posting here. The therein mentioned projects are mainly working now, and I've also produced a SQLite browser application similar to the Postgresql one. My "newdialogs" are mostly working as well, although there's one annoying effect left, making the main form "blink" for a moment when one is closed. I hope to get this eliminated. But I've a BIG gripe to present: At least with the current ide, debugging has evolved to a nightmare. That the debugger crashes for any minor reason, like being pointed to a dynamic array (ANY dynamic array variable, not just uninitialized ones), is a minor problem here. The real nuisance is the handling of editor files. Assume you have a unit file open and try to compile the program, but there is an error in the unit file. THis leads unconditionally to another instance of the unit file to be opened to presnt the error, AND if the unit has a form, complain that the form file CANNOT be opened correctly, instead opening it as an ordinary text file AND setting THIS as the active editor file. This is completely reproducible here. And the same procedure happens even without an error on running a program up to a breakpoint set with in an ipen editor file - it gets RELOADED a second time, and the ide complains about an unability to also load the uni's form as a form, instead presenting it as a text file. This also happens, "of course", when a real error occurs during running a program. It looks a bit like a problem with the editor's file management, which cannot recognize whether a file is already open or hust blindly tries to load any file or "unit" handed it by some other function, but alway<s trying to open a source and a form file together. That's really annoying duringdebugging, when you try to set and clear breakpoints as needed, as by doing this, you often PROVOKE such a multiple load process and the ensuing complaint from the editor, distracting you from what you wanted to achieve or observe. I DO hope that this is just affecting "me" (my system), as I'm using a not so really common variant of Linux,albeit a current one: Slackware Linux version 15 for x86_64, kernel 6.6.15 on AMD A10-9700 with RADEON R7 graphics, using plain X11 with the openbox window manager and NO "desktop environment"..The ide causing the problems wascompiled with FPC 3.2.2, but works identically when compiled with FPC 3.3.1, using msegui version 5.10.2 (although the behaviour, though not thoroughly observed, also existed already for a few of the previous versions). I hope this helps to investigate - and reproduce - the problem and it's correction. Thank you very much, and have a good time nonetheless. BTW, I'll probabely "publish" the latest project sources on my web site soon, but I'd like to correct the remaining issues first, if possible. I'll give you notice here. -- (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...> - 2024-05-08 00:13:22
|
Hello mohamed, you wrote on Tue, 7 May 2024 18:06:32 +0000: > I got the errors when building PSQLBrowse.prj. Please see attn. As Fred wrote already, the ./units (or, on Windows, the .\units) directory doesn't exist in your project directory. Check the project file and make sure that all of the settings there are satisfied, then the project should compile correctly. And yes, you should use my modified units in case you want to make use of either the "newdialogs" units, the (slightly) extended "stat" units or the extended PostgreSQL or other modified db units or check out the PostgreSQL or PSQLite browser example programs. Success, and happy computing & compiling! -- (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...> - 2024-05-09 10:58:15
Attachments:
Capture.PNG
|
HELLO ALL, SOME UNITS ARE NOT AVAIL. SEE ATTN BEST REGARDS. ________________________________ De : Sieghard via mseide-msegui-talk <mse...@li...> Envoyé : mardi 7 mai 2024 22:51 À : mse...@li... <mse...@li...> Cc : Sieghard <s_...@ar...> Objet : Re: [MSEide-MSEgui-talk] New release 5.10.0. Hello mohamed, you wrote on Tue, 7 May 2024 18:06:32 +0000: > I got the errors when building PSQLBrowse.prj. Please see attn. As Fred wrote already, the ./units (or, on Windows, the .\units) directory doesn't exist in your project directory. Check the project file and make sure that all of the settings there are satisfied, then the project should compile correctly. And yes, you should use my modified units in case you want to make use of either the "newdialogs" units, the (slightly) extended "stat" units or the extended PostgreSQL or other modified db units or check out the PostgreSQL or PSQLite browser example programs. Success, and happy computing & compiling! -- (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...> - 2024-05-09 11:24:12
|
Hello Med. Indeed, I just have tried to compile PSQLBrowse.prj for Windows and I get the same error message. If removing "cLocale" in uses section of SQLForm.pas then there is a other error: fontlist.pas(297,4) Fatal: Syntax error, "INTERFACE" expected but "END" found Imho, PSQLBrowse.prj needs some tweak to work for Windows. PS: Compiling for Linux is ok (but i did not test it because I dont have libpq.so installed). Fre;D ________________________________ De : mohamed hamza <me...@ho...> Envoyé : jeudi 9 mai 2024 12:58 À : General list for MSEide+MSEgui <mse...@li...> Objet : Re: [MSEide-MSEgui-talk] New release 5.10.0. HELLO ALL, SOME UNITS ARE NOT AVAIL. SEE ATTN BEST REGARDS. ________________________________ De : Sieghard via mseide-msegui-talk <mse...@li...> Envoyé : mardi 7 mai 2024 22:51 À : mse...@li... <mse...@li...> Cc : Sieghard <s_...@ar...> Objet : Re: [MSEide-MSEgui-talk] New release 5.10.0. Hello mohamed, you wrote on Tue, 7 May 2024 18:06:32 +0000: > I got the errors when building PSQLBrowse.prj. Please see attn. As Fred wrote already, the ./units (or, on Windows, the .\units) directory doesn't exist in your project directory. Check the project file and make sure that all of the settings there are satisfied, then the project should compile correctly. And yes, you should use my modified units in case you want to make use of either the "newdialogs" units, the (slightly) extended "stat" units or the extended PostgreSQL or other modified db units or check out the PostgreSQL or PSQLite browser example programs. Success, and happy computing & compiling! -- (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...> - 2024-05-08 10:13:19
|
Hello Fred,
you wrote on Tue, 7 May 2024 13:19:32 +0000:
> There is a little problem with MSEClock window what not redrawn correctly
> when resized.
> If resize the window (and change only the height), the window isn't
> redrawn properly. If clicking into the window, then it is redrawn
> properly.
Yes, that's intended. The window resizing is explicitely made to maintain a
constant aperture ratio, i.e. width-to-height ratio. And the decisive
parameter for setting the absolute size is its width, meaning you have to
change the WIDTH to change the size. If you want, you canchange this, but I
found the resulting display mostly not so good looking, prompting me to
introduce that little quirk to keep it "pleasant"
So no measures from my side here, at least if I understood you correctly.
> Also, only with Windows 64 bit, compiling MSEide with msegui-sieghard
> branch, there is that error:
>
> mpqconnection.pas(1264,20) Error: (4004) Variable identifier expected
Thank you for reporting. That's indeed interesting, since that same
statement compiles without problem under Linux with fpc. Indeed, it does
NOT compile with the "ar8ty" cast, but produces the DIFFERENT error message
'Error: Identifier not found "beton8"'.
So this most probabely is a Windows specific problem, where the "currency"
type seems to be defined slightly differently, and where the endian shuffle
function "beton8" possibly is defined differently, with another parameter
signature, probabely.
It might be neccessary so to introduce a system dependent compilation
conditional to provide the correct type coertion expression.
(BTW, the FPC "ref.pdf" documentation text says toward this:
"The currency type is a fixed-point real data type which is internally used
as an 64-bit integer type (automatically scaled with a factor 10000), this
minimizes rounding errors.". So this is not exactly defined - and there's
no type definition to be found in the FPC sources, even - and seems to be
compatible to an int64 on Linux only, but not on Windows.)
Perhaps the following might do, at least for FPC:
// Added for recent postgresql versions (28. Mar 2024 22:54:58):
{$ifdef FPC}
{$ifdef WINDOWS}
int64 (ar8ty (cur)):= beton8 (pint64 (currbuff)^);
{$else}
int64 (cur):= beton (pint64 (currbuff)^); // point here
{$endif}
{$else}
int64 (ar8ty (cur)):= beton8 (pint64 (currbuff)^);
{$endif}
This will not help for a different Pascal compiler, but that's probabely
not really been tested already at all...
I hope this gives you sufficient, though possibly not satisfying, answers
to your requests,
Thank you again for your information, 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: Fred vS <fi...@ho...> - 2024-05-08 11:42:23
Attachments:
mseclock_resize.png
|
Hello Sieghard. Thanks for your explanations. But maybe you did not see the screenshot when resizing MSEClocK. I will try to add it as attachment (maybe sf will accept it now). There is also a problem with moving the window by clicking on the form, holding the button clicked and trying to move the window with the mouse. The form starts flashing and is placed in a random position. Maybe both resize and moving form problems are related. Have a nice day. Fre;D |
|
From: Sieghard <s_...@ar...> - 2024-05-15 22:13:19
|
Hello Fred, you wrote on Tue, 14 May 2024 22:55:29 +0000: > I think that I understand better the problem (maybe). You're probably on the track. > If you use a tfilenameeditx, via le Object Inspector, there is the > property "statfile" where you can assign a config file. ... That seems to be somewhat the same as I used for the popup calendar form, but that one is much simpler than the file dialog. Specifically, it does not have a controller. The filedialogcontroller acts as an _insulating_ layer between the caller and the finally displayed form, and as implemented does not even allow any direct data exchange with the form that it caters for, even creates, itself. With your extended file dialog, that assumption broke down, and you had to introduce a lot of _form_ state information in the controller to allow at least some control for the caller. The inception of the "newdialogs" version was even to have _full_ control of the visible form from the application level and to be able to save and retrieve it automatically The first goal was meant to be achieved by creating a fully initialized form (or passing one to the controller) for display and have the application take care of it, and the second was to be solved by the use of the - rather opaque and inscrutable - memory stat file mechanism. Both approaches worked quite well for the simpler dialogs, albeit with "a little help from some friends" for a couple of them (the calendar form, notably). The file dialog showed up as an exception, though, and mainly because of its special use of an insulating layer, the controller, which required a lot of modifications to even get close to my first goal, handing over a fully pre-initialized form, and makes it quite tedious to achieve the second one, although I _think_ I found a way to make it perform as I want. > So the trick is to assign to filedialogxfo the same "statfile" used by > > <tfilenameeditx. ... > I dont know if it is the problem that you related but yes, this could be > a solution. Yes, that's an indirect call to the whole stuff suffering from all the same limits, specifically it has to use all of the same tricks for retrieving and saveing state information of the deeply insulated form object. It cannot help to carry all these multiplied variables around and keeps the opacity of the construct. It's probabely meant for use from within some other object for casual use of a file dialog (a grid cell, perhaps?), which is by itself closely limited and which it can serve satisfactorily. I'd be more satisfied if no additional layer was needed. Many thanks for your valuable suggestions, and my apologies for my always overly lengthy explications As always, best wishes, 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 ----------------------------------------------------------- |
Thanks for helping keep SourceForge clean.
X