You can subscribe to this list here.
2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(6) |
Nov
(203) |
Dec
(466) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2012 |
Jan
(358) |
Feb
(288) |
Mar
(305) |
Apr
(240) |
May
(85) |
Jun
(146) |
Jul
(485) |
Aug
(631) |
Sep
(549) |
Oct
(234) |
Nov
(97) |
Dec
(273) |
2013 |
Jan
(225) |
Feb
(93) |
Mar
(196) |
Apr
(129) |
May
(37) |
Jun
(171) |
Jul
(153) |
Aug
(82) |
Sep
(88) |
Oct
(208) |
Nov
(708) |
Dec
(77) |
2014 |
Jan
(252) |
Feb
(99) |
Mar
(118) |
Apr
(192) |
May
(68) |
Jun
(63) |
Jul
(74) |
Aug
(90) |
Sep
(133) |
Oct
(80) |
Nov
(195) |
Dec
(290) |
2015 |
Jan
(127) |
Feb
(73) |
Mar
(167) |
Apr
(34) |
May
(14) |
Jun
(308) |
Jul
(23) |
Aug
(69) |
Sep
(103) |
Oct
(95) |
Nov
(22) |
Dec
(277) |
2016 |
Jan
(209) |
Feb
(80) |
Mar
(40) |
Apr
(296) |
May
(146) |
Jun
(41) |
Jul
(55) |
Aug
(101) |
Sep
(161) |
Oct
(187) |
Nov
(144) |
Dec
(64) |
2017 |
Jan
(16) |
Feb
(38) |
Mar
(117) |
Apr
(105) |
May
(90) |
Jun
(52) |
Jul
(148) |
Aug
(117) |
Sep
(169) |
Oct
(97) |
Nov
(79) |
Dec
(58) |
2018 |
Jan
(77) |
Feb
(54) |
Mar
(144) |
Apr
(21) |
May
(46) |
Jun
(147) |
Jul
(134) |
Aug
(86) |
Sep
(185) |
Oct
(56) |
Nov
(75) |
Dec
(80) |
2019 |
Jan
(60) |
Feb
(82) |
Mar
(25) |
Apr
(124) |
May
(25) |
Jun
(10) |
Jul
(9) |
Aug
(64) |
Sep
(18) |
Oct
(17) |
Nov
(19) |
Dec
|
2020 |
Jan
(26) |
Feb
(87) |
Mar
(113) |
Apr
(74) |
May
(27) |
Jun
(15) |
Jul
|
Aug
(25) |
Sep
(42) |
Oct
|
Nov
|
Dec
(39) |
2021 |
Jan
(22) |
Feb
(12) |
Mar
(297) |
Apr
(132) |
May
(134) |
Jun
(52) |
Jul
(83) |
Aug
(10) |
Sep
(4) |
Oct
(16) |
Nov
(9) |
Dec
|
2022 |
Jan
(50) |
Feb
(68) |
Mar
(76) |
Apr
(12) |
May
(4) |
Jun
(44) |
Jul
(6) |
Aug
(3) |
Sep
(47) |
Oct
(56) |
Nov
(31) |
Dec
(7) |
2023 |
Jan
(6) |
Feb
(1) |
Mar
(24) |
Apr
|
May
(20) |
Jun
(89) |
Jul
(69) |
Aug
(114) |
Sep
(82) |
Oct
(6) |
Nov
|
Dec
|
2024 |
Jan
(10) |
Feb
(9) |
Mar
(3) |
Apr
(7) |
May
(55) |
Jun
(9) |
Jul
(2) |
Aug
(11) |
Sep
|
Oct
|
Nov
|
Dec
|
From: Sieghard <s_...@ar...> - 2024-05-09 22:13:23
|
Hello Fred, you wrote on Thu, 9 May 2024 15:17:44 +0000: > Thanks for the new fixes, I will commit it asap in the sieghard branch. Thank you for promoting. I hope this can fix the issues. > I understand that you dont want to have a Github account but it would be > great if you could check regulary that discussion: It's not so that I didn't want a Github account (even though that's now a Microsoft "installment"), but that the discussions there can't be followed by an automated process like usenet groups can - and _this_ list works that way, even though it is really a converted mailing list. But I might check whether claws mail can possibly support such a system - an internet "forum", I supppose? - and give it a try if there's a chance. I just DON'T want to keep my machine always open to the internet, that's like ripping out the front door and placing a "welcome" sign beside the entrance. The result seems to escape the awareness of most every internet user up to now, although it already provoked legal measures by many authorities, requiring potential victims to simply "help themselves", implementing potentially drastic measures. Well... > So I dont have to post here each new messages. I'm very grateful that you do, and would like to relieve you. I'll be sure to check the link you gave, but as I don't "surf" the internet that often, it maytake some time. Best wishes! -- (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-09 22:13:17
|
Hello Fred, might I present a stupid suggestion for handling msegui branches? I always wondered why Martin put his library components into a SUBdirectory of the real "lib" directory. And as I supposed him to have that done on purpose, I came to the conclusion he might have done that to allow for sepecial PARALLEL branches besides the "common" area, which probabely was meant for those parts that should be - as the name suggests - COMMON to all the project's library units covered by the whole system. I even had used that for some time to place my "newdialogs" beside "common" and address it through some project options (Fu definitions). Putting these in a place where they are accessed _before_ any of the "common" branch, the compiler would resolve any requirements from there and later ignore the "original" definitions or nits from "common", as intended. This could be a method to provide several regularöy distributed branches, as well as a means for any user working on one or even several large projects to keep his own librarie's code easily accessible, yet still on a level where it belongs. (And, of cousre, the "Fu" definitions also work for other locations on a developer's machine, allowing him to access several components from different sources.) As I stated above, just a silly suggestion. Happy coding, 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-09 15:18:01
|
Hello Sieghard. Thanks for the new fixes, I will commit it asap in the sieghard branch. I understand that you dont want to have a Github account but it would be great if you could check regulary that discussion: https://github.com/mse-org/mseide-msegui/discussions/87 So I dont have to post here each new messages. Have lot of fun too. Fre;D |
From: Sieghard <s_...@ar...> - 2024-05-09 15:03:32
|
Hello Fred, you wrote on Thu, 9 May 2024 11:23:59 +0000: > Indeed, I just have tried to compile PSQLBrowse.prj for Windows and I get > the same error message. As I found out, this is because that's a Unix-only unit and not applicable on and for Windows. > 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 Well, that's because on non-Unixen, this unit evaluates to an empty unit, although even devoid of the - seemingly - required statements "Interface" and "Implementation". I added these in an "else" clause of the encompassing compiler conditional to "keep the compiler happy", as you use to say. > Imho, PSQLBrowse.prj needs some tweak to work for Windows. Yes, certainly. DIDN'T I state that I can only test it on Linux? Currently, I've not even an emulator that does work, and no functioning "wine" as well. Thus, anyone wanting to use the units on Windows has to test it himself, sadly. > PS: Compiling for Linux is ok (but i did not test it because I dont have > libpq.so installed). It would have happend the same with the SQLiteBrowser, they're very similar. Anyway, I put the modified version on my web site, so at least these two issues should be resolved that way. Have a lot of fun... -- (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-09 14:45:15
|
Hello mohamed, you "yelled" on Thu, 9 May 2024 10:58:00 +0000: > HELLO ALL, > > SOME UNITS ARE NOT AVAIL. SEE ATTN > > BEST REGARDS. Indeed. This didn't occur to me at all, as I'm exclusively orking on Linux here, and THERE, this is a standard FPC unit. The FPC documentation says in "user.pdf": 9.4 Under Linux and BSD-like platforms ... clocale This unit initializes the internationalization settings in the sysutils unit with settings ob- tained through the C library. It doesn't exist on Windows. This is confirmed by the description in the "rtl.pdf" documentation: Reference for unit ’clocale’ 5.1 Overview .... It makes no sense to use this unit on a non-POSIX system: Windows, OS/2 or DOS - therefore it should always be between an ifdef statement: Please add such a conditional around the reference to this unit, I will include one in the code on my web site as well. Sorry for the oversight. I hope the units will work all right for you on Windows also. -- (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-09 14:40:20
|
Hello Fred, this is just a short note to inform you and all users that there are new versions of the "newdialogs" and "FileRequest" 'packages' on my web site. The modifications are very minor, just a formatting correction for the "newdialogs" and enabling the "return" key for terminating the "X" version of the "FileRequest" program to accept the current selection. -- (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-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: mohamed h. <me...@ho...> - 2024-05-09 10:58:15
|
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-08 22:52:25
|
Hello Sieghard. Newdialogs fixes have been committed to the sieghard-branch and MSEclock + new demo here: https://github.com/mse-org/mseide-msegui/discussions/87#discussioncomment-9361181 Thanks a lot for the fixes and the new demo and have precious vibes. Fre;D |
From: Sieghard <s_...@ar...> - 2024-05-08 22:13:17
|
Hello Fred, you wrote on Wed, 8 May 2024 11:42:15 +0000: > There is also a problem with moving the window by clicking on the form, Yes, this function was in error. Reason was a wrong use of the placement code after the "keepOnScreen" was modified in the course of the development of the "newdialogs". The new version on my web site has the, after all, very simple correction. There is also a new version of the "newdialogs" with a couple minor changes, and a new example application named "FileRequester". This is a stand-alone version of the "msefiledialog(x)" dialog from the "newdialogs" meant for use within scripts to provide file selections or even for "self-contained" applications like viewing pictures, videos or selecting files for processing by other applications that can be called from within it. Have a look on the "README" file to see what it provides. Have a pleasant time, 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...> - 2024-05-08 21:48:43
|
Hello Fred, you wrote on Wed, 8 May 2024 11:42:15 +0000: > 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). The screenshot worked as an attachement, but it didn't really help. > There is also a problem with moving the window by clicking on the form, THIS is the explanation for my failing to reproduce your problem correctly. I just did the (resizing and) moving the usual way by clicking and holding the mouse button on the window TITLE BAR. This works witout any problem, probabely because it is executed by the window manager. > holding the button clicked and trying to move the window with the mouse. > The form starts flashing and is placed in a random position. But the extension intended to allow for MOVING (not resizing) the form, specifically when no border ("window decoration on Linux) is used, provokes the erratic movement you descibe, and it often even "loses" the window at an unexpected position. I don't really remenber where the code for this function emerged, I think you posted it here, even, but it didn't seem to behave that way when I implemented it. This was a long time from now, and as I don't really use the MSEclock program myself, I didn't regularly inspect it for such - seemingly newly acquired - quirks. It might even have to do with the function "keepOnScreen" that should make sure dialog forms aren't placed outside the display area. Although this was moved to the "msedialog" unit, I did also use it for the form-internal mouse positioning. It does seem to not be really suitable for that use. > Maybe both resize and moving form problems are related. No, the sizing effect is indeed intended so, but the moving problem is definietely not. I'll investigate the cause and try to reolve it. I'll give you notice. Thank you for reporting, 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
|
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-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: 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: Fred vS <fi...@ho...> - 2024-05-07 18:26:14
|
Hello Med. The error message is because the directory \units does not exist. You should create it manually. I suppose that you are esting PSQLbrowse project of Sieghard downloaded from here. https://github.com/mse-org/mseide-msegui/discussions/87 If so, be sure to compile it with the sieghard-branch: https://github.com/mse-org/mseide-msegui/tree/sieghard Fre;D ________________________________ De : mohamed hamza <me...@ho...> Envoyé : mardi 7 mai 2024 20:06 À : General list for MSEide+MSEgui <mse...@li...> Objet : Re: [MSEide-MSEgui-talk] New release 5.10.0. Hi All, I got the errors when building PSQLBrowse.prj. Please see attn. Best Regards. M.HAMZA ________________________________ |
From: mohamed h. <me...@ho...> - 2024-05-07 18:06:48
|
Hi All, I got the errors when building PSQLBrowse.prj. Please see attn. Best Regards. M.HAMZA ________________________________ De : Fred vS <fi...@ho...> Envoyé : mardi 7 mai 2024 13:19 À : General list for MSEide+MSEgui <mse...@li...> Objet : Re: [MSEide-MSEgui-talk] New release 5.10.0. Hello Sieghard. Many thanks for the fixes in newdialogs, (nearly) all seems ok now. 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. See here:https://github.com/mse-org/mseide-msegui/issues/90 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 This point to: ------------------------ // Added for recent postgresql versions (28. Mar 2024 22:54:58): {$ifdef FPC} int64 (cur):= beton (pint64 (currbuff)^); // point here {$else} int64(ar8ty (cur)):= beton8 (pint64 (currbuff)^); {$endif} -------------------------- If changing with this (but not sure if it is ok) the compilation is ok: ---------------------- // Added for recent postgresql versions (28. Mar 2024 22:54:58): ftCurrency: begin {$ifdef FPC} int64(ar8ty (cur)):= beton (pint64 (currbuff)^); // here adding ar8ty() {$else} int64(ar8ty (cur)):= beton8 (pint64 (currbuff)^); {$endif} ______________ Otherwise all seems perfect. Have a perfect day. Fre;D |
From: Fred vS <fi...@ho...> - 2024-05-07 13:19:40
|
Hello Sieghard. Many thanks for the fixes in newdialogs, (nearly) all seems ok now. 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. See here:https://github.com/mse-org/mseide-msegui/issues/90 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 This point to: ------------------------ // Added for recent postgresql versions (28. Mar 2024 22:54:58): {$ifdef FPC} int64 (cur):= beton (pint64 (currbuff)^); // point here {$else} int64(ar8ty (cur)):= beton8 (pint64 (currbuff)^); {$endif} -------------------------- If changing with this (but not sure if it is ok) the compilation is ok: ---------------------- // Added for recent postgresql versions (28. Mar 2024 22:54:58): ftCurrency: begin {$ifdef FPC} int64(ar8ty (cur)):= beton (pint64 (currbuff)^); // here adding ar8ty() {$else} int64(ar8ty (cur)):= beton8 (pint64 (currbuff)^); {$endif} ______________ Otherwise all seems perfect. Have a perfect day. Fre;D |
From: Sieghard <s_...@ar...> - 2024-05-05 11:13:30
|
Hello Fred, you wrote on Sat, 4 May 2024 01:04:18 +0000: > Many thanks for the fixes, they are commited/pushed to the sieghard > branch: https://github.com/mse-org/mseide-msegui/tree/sieghard Thank you for publishing. > Will test it deeply (and thanks for the fix in filedialogx.pas too). I hope they work out for you and everyone who attempts to use them. The "newdialogs" are still experimental, don't you please forget. BTW, the fix is not in the filedialog, it's in the basic modified version of the "msedialog" unit, and also adresses the blinking problem, which was the real culprit. Keep up the good work, and enjoy the weekend! -- (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-04 01:04:31
|
Hello Sieghard! Many thanks for the fixes, they are commited/pushed to the sieghard branch: https://github.com/mse-org/mseide-msegui/tree/sieghard Will test it deeply (and thanks for the fix in filedialogx.pas too). Fre;D |
From: Sieghard <s_...@ar...> - 2024-05-04 00:30:09
|
Hello Fred, you wrote on Thu, 2 May 2024 22:55:16 +0000: > 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. Thank you again for the report - although this doesn't seem to be connected to the REAL underlying problem, it did certainly pique me to investigate deeper. And also to observe the system independent parts more closely. But finally, the real cause was something quite unexpected, only caused by an oversight from my part. I reused - misused - a data structure defining window properties that "is already there", but not fully used, to allow for passing more information. This worked - but only for the most part. And it DIDN'T work for that part that was the least to be suspected, the case when no specific positioning was to be done. In this case, a false flag (dp_none, equivalent to "fo_main"!) was set, and this did lead the window management functions to clear all of the application's windows when just the dialog was closed. The other placement options do work correctly and did before, as they have the same values as the equivalent original ones. So the remedy for this big issue is a very simple minor modification in the initialization code that just doesn't set the flag when not needed... The new version on my web site contains this correction, in addition to the addition of a new "DialogPlacement" variable for the file dialog controller which allows to programmatically specify where a file dialog should be shown. As a minor aside, I put a patched version for the linux "mseguiintf" unit (file "mseguiintf_patched.zip") there, in case you wanted to check it out. It has the modification that seems to avoid some "not decorated" errors, and at least reduces the long delay before they appear, should one occur anyway. It also suppresses the Xorg gui error caused by a false call for setting the X input focus in such cases. But that's just a minor problem, usually without consequences, except for those possible sporadic "not decorated" messages. It might just not hurt... Thank you again for your support and 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: Sieghard <s_...@ar...> - 2024-05-03 15:13:22
|
Hello Fred, you wrote on Thu, 2 May 2024 22:55:16 +0000: > 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. This might be an important observation, thank you for reporting. ... > Yes, there are problems with Windows too. Which relocates the problem from the X11 interface units to something deeper in the system... not making it easier to resolve, though. But anyway, thank you also for reporting this. -- (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: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: 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: 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: 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 ----------------------------------------------------------- |