Menu
▾
▴
mseide-msegui-talk
|
From: Sieghard <s_...@ar...> - 2024-04-19 13:13:23
|
Hello Fred, you wrote on Thu, 18 Apr 2024 21:26:19 +0000: > I apologize for the late answer. No reason - it's not that urgent anyway. > >The therein mentioned > projects are mainly working now, and I've also produced a SQLite browser ... > Thanks for this great addition, I will test it deeply asap. Well, they're probabely not that great, though they might serve as simple- minded examples. They're somewhat centered around the "newdialogs", but, with "a few" modifications, might be made useable with the standard dialogs also. But I've not tried that and thus don't know how to do it. > >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. Yes, I can imagine, now. Especially when you're using a windows system for your work, you might not even be able to set up the ide to produce the problem. I'm working - exclusively - under Linux (I specified my system in my latest posting). As I'm a lazy gui, I put a link to the "newdialogs" directory in the current working directory to have an easy access to units that might have to be modified. And when I'd opened a file from this link to modify or place a breakpoint, that's when the editor gets confused. It doesn't recognize that a file it attempts to load from an internal request that that's the same file, probabely because it doen't resolve the link (although there are msegui functions for that, as I saw) and only checks the file path (which is reasonable). Thus, the problem essentially turns out to some amount of misuse, caused by, kind of, (my) overly optimistic assumptions concerning the abilities of the tool set used. > Could you, please, test your project with the latest mseide from Martin: I realized that when I did this, and found the same, well, effects occurring even with the original "historic" ide. This led me to a bit further thought and investigation, and so I found the REAL cause for my - thus self-inflicted - annoyance. So, there's no fault with the ide. One might just wonder whether it might be of use to warn the user when he attempts to load a file of the same name as one already open, to avoid HIM getting confused what he is working on. Or, on Unixen, always fully resolve paths for comparison during loading to avoid multiple openings. This might even be appropriate in cases where one sets breakpoints in an indirectly opened file that the debugger recognizes as part of the project (and that even gets marked for code referencess (blue dots) and breakpoints (red dots). That's probabely what caused my confusion in the first place. After all, this was a false alarm only, and everything works as intended, except when a nosy user attempts to outsmart his tools. So I hope I didn't cause you too much inconvenience and could finally clarify the cause. In the end, I have to thank you for your help and patience, and I wish you a nice and trouble-free weekend. -- (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-19 22:13:21
|
Hello Fred, well, now at long last I've been able to upload the files pertaining to my latest undertakings. It took me a while because of a modification of my hoster concerning the access to their "control panel" and my web site data. Now you can again find the latest files at the usual address. There's quite a number there, now, because I separated them into independent components: newdialogs.zip of course, the "new dialogs" msegui_memorystatfile_patches.zip extented "msestatfile" unit msegui_lib_db_patches.zip a couple patches for the db units, relevant mostly/only for Postgresql MSEclock.zip the good old MSEclock updated PSQLbrowse.zip browser for Postgresql databases SQLiteBrowse.zip similar browser for SQLite databases PV_Data.zip some sample data for database testing All the sample programs rely on the "newdialogs", although they should be adaptable to use the "traditional" ones also. The db unit patches are required only for the PSQLbrowser, to allow for Postgresql's additional "interval" and "money" datatypes. SQLite doesn't know such, so it doesn't need the modifications. "PV_Data.zip" contains a SQLite database file of one year's worth of measurements of a PV installation, which can be used to produce some nice graphic displays. It also contains a dump of the same data for use with Postgresql or other SQL-based database systems. You can peruse the sample database data as you like, even publish them, as long as you don't disclose their source. For themselves, they should be sufficiently neutral and anonymous. Of course, the patch fles and the "newdialogs" are meant for consideration for integration into msegui, and I'm awaiting your comments and requests for modification. Finally, the sample programs are meant just as such: examples for some of the functionality of msegui and how it can be used to produce something (hopefully) useful... Thank you for your consideration, and keep up the good work! (And please take my apology for the fuss about my misunderstandig of the ide source file handling.) -- (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-23 21:04:05
|
Hello Sieghard. Many, many thanks for that great code. I tried the newdialogs components on Linux and everything seems ok, same for the stat files. For db files, because I don't know how thoroughly to test it, it's on the to-do list. Started a discussion on Github-mseide-msegui site and added the zipped files from your site: https://github.com/mse-org/mseide-msegui/discussions/87 It would be great if other people try it on other OS too. For all the new DB things (SQLiteBrowse.zip, PV_Data.zip,PSQLbrowse.zip), I will jump into it asap. Many, many thanks. Fre;D ________________________________ De : Sieghard via mseide-msegui-talk <mse...@li...> Envoyé : vendredi 19 avril 2024 23:46 À : mse...@li... <mse...@li...> Cc : Sieghard <s_...@ar...> Objet : Re: [MSEide-MSEgui-talk] New release 5.10.0. Hello Fred, well, now at long last I've been able to upload the files pertaining to my latest undertakings. It took me a while because of a modification of my hoster concerning the access to their "control panel" and my web site data. Now you can again find the latest files at the usual address. There's quite a number there, now, because I separated them into independent components: newdialogs.zip of course, the "new dialogs" msegui_memorystatfile_patches.zip extented "msestatfile" unit msegui_lib_db_patches.zip a couple patches for the db units, relevant mostly/only for Postgresql MSEclock.zip the good old MSEclock updated PSQLbrowse.zip browser for Postgresql databases SQLiteBrowse.zip similar browser for SQLite databases PV_Data.zip some sample data for database testing All the sample programs rely on the "newdialogs", although they should be adaptable to use the "traditional" ones also. The db unit patches are required only for the PSQLbrowser, to allow for Postgresql's additional "interval" and "money" datatypes. SQLite doesn't know such, so it doesn't need the modifications. "PV_Data.zip" contains a SQLite database file of one year's worth of measurements of a PV installation, which can be used to produce some nice graphic displays. It also contains a dump of the same data for use with Postgresql or other SQL-based database systems. You can peruse the sample database data as you like, even publish them, as long as you don't disclose their source. For themselves, they should be sufficiently neutral and anonymous. Of course, the patch fles and the "newdialogs" are meant for consideration for integration into msegui, and I'm awaiting your comments and requests for modification. Finally, the sample programs are meant just as such: examples for some of the functionality of msegui and how it can be used to produce something (hopefully) useful... Thank you for your consideration, and keep up the good work! (And please take my apology for the fuss about my misunderstandig of the ide source file handling.) -- (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-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-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: 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: 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-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 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-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: Sieghard <s_...@ar...> - 2024-04-24 22:13:24
|
Hello Fred, you wrote on Tue, 23 Apr 2024 21:03:50 +0000: > I tried the newdialogs components on Linux and everything seems ok, same > for the stat files. For db files, because I don't know how thoroughly to > test it, it's on the to-do list. Fine to read that everything seems to work for you too, and thank you for the time you spent on reviewing and reporting. > Started a discussion on Github-mseide-msegui site and added the zipped > files from your site: ... > It would be great if other people try it on other OS too. Yes, that would be good in any case, and even more so if mseide-msegui could thereby get some publicity and perhaps a few new users. BTW, I recently got notice of the CVE (Common Vulnerability Evaluation) lists from <https://www.cve.org/>? That's a HUGE collection of software vulnerabilities against intrusion and misuse, ranging from 1999 till "today". They're available on github too, providing all the records on <https://raw.githubusercontent.com/CVEProject>. But beware: the zip file is over 300 MBytes in size! I mention that because I was curious what might be on record for Free Pascal, Lazarus and, of course, mseide-msegui. Well, the result is very satifying: There's NOTHING to be found. (But, of course I hope that's not just because there's close to nothing around in use built from any of these...) > For all the new DB things (SQLiteBrowse.zip, PV_Data.zip,PSQLbrowse.zip), > I will jump into it asap. You can check out the SQLiteBrowser quite easily by rummaging about in your Firefox and possibly Thunderbird profile directories. The mozilla programs like to store a lot of data in .sqlite files, many even keeping more than one table per file (where a file is equivalent to a "database" for SQLite). And you can immediately use the sample database .sqlite file from the "PV_Data.zip" file. And perhaps some other user can modify the PSQLbrowse program to work with maria db aka mysql? I just don't have a use for it, and thus I haven't installed it. (And my backup disks are prone to overflow anyway nonethess I try to keep my disks mostly uncluttered...) But don't hurry, take your time, do thoroughly whar you do, and please report problems timely so I can fix them. I realize that this is a lot at once, so again, don't hurry. After all, I wish you all the best and always success. As martin used to say: 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: Fred vS <fi...@ho...> - 2024-05-01 15:58:52
|
Hello everybody. There is a new branch with the Sieghard newdialogs, statfile fixes and extended db here: https://github.com/mse-org/mseide-msegui/tree/sieghard MSEide works on MacOS also for compiling and running projects. https://github.com/mse-org/mseide-msegui/discussions/65#discussioncomment-9281175 The binary of MSEide.app was added in assets of release. Have nice and funny days. Fre;D ________________________________ De : Sieghard via mseide-msegui-talk <mse...@li...> Envoyé : mercredi 24 avril 2024 22:31 À : mse...@li... <mse...@li...> Cc : Sieghard <s_...@ar...> Objet : Re: [MSEide-MSEgui-talk] New release 5.10.0. Hello Fred, you wrote on Tue, 23 Apr 2024 21:03:50 +0000: > I tried the newdialogs components on Linux and everything seems ok, same > for the stat files. For db files, because I don't know how thoroughly to > test it, it's on the to-do list. Fine to read that everything seems to work for you too, and thank you for the time you spent on reviewing and reporting. > Started a discussion on Github-mseide-msegui site and added the zipped > files from your site: ... > It would be great if other people try it on other OS too. Yes, that would be good in any case, and even more so if mseide-msegui could thereby get some publicity and perhaps a few new users. BTW, I recently got notice of the CVE (Common Vulnerability Evaluation) lists from <https://www.cve.org/>? That's a HUGE collection of software vulnerabilities against intrusion and misuse, ranging from 1999 till "today". They're available on github too, providing all the records on <https://raw.githubusercontent.com/CVEProject>. But beware: the zip file is over 300 MBytes in size! I mention that because I was curious what might be on record for Free Pascal, Lazarus and, of course, mseide-msegui. Well, the result is very satifying: There's NOTHING to be found. (But, of course I hope that's not just because there's close to nothing around in use built from any of these...) > For all the new DB things (SQLiteBrowse.zip, PV_Data.zip,PSQLbrowse.zip), > I will jump into it asap. You can check out the SQLiteBrowser quite easily by rummaging about in your Firefox and possibly Thunderbird profile directories. The mozilla programs like to store a lot of data in .sqlite files, many even keeping more than one table per file (where a file is equivalent to a "database" for SQLite). And you can immediately use the sample database .sqlite file from the "PV_Data.zip" file. And perhaps some other user can modify the PSQLbrowse program to work with maria db aka mysql? I just don't have a use for it, and thus I haven't installed it. (And my backup disks are prone to overflow anyway nonethess I try to keep my disks mostly uncluttered...) But don't hurry, take your time, do thoroughly whar you do, and please report problems timely so I can fix them. I realize that this is a lot at once, so again, don't hurry. After all, I wish you all the best and always success. As martin used to say: 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 ----------------------------------------------------------- _______________________________________________ mseide-msegui-talk mailing list mse...@li... https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk |
|
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: 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: 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 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: Sieghard <s_...@ar...> - 2024-05-14 00:13:24
|
Hello Fred, I have a question concerning your extended filedialogx. I've run into severe problems with its statfile handling. It seems to me that saving the layout dependent settings simply cannot work. This concerns such things as display of icons, places column and even the settings bar itself. They are meant to be written to the statfile by the filedialogxcontroller when the dialog is closed. THe values of the form elements are meant to be passed by separate variables defined in the controller, but they cannot be set before the time when the controller's writestat functions execute. This means the current values will never be written to the statfile, although the controller can correctly _read_ the old values every time when executed, and will thus always present the state when the application was designed. That was - perhaps - fine for the old dialog structure, where no user mede modifications were intended anyway. It is a severe road block for "my" newdialogs, where this ought to be a major feature. There seem to be several possible ways to resolve this issue. One is, of course, directly changing all of these variables immediately if they're modified by the form; this could work already, because I had to add a reference to the controller anyway. But I would like to avoid this heavy duplicating of data and the requirement to carefully keep track of all interdependent instances and the error potential of missing any of them. Another measure might be to simply giving the controller direct access to the form. Totally contrary to the naming, the controller has NO CONTROL of the form it shows! Even though it can be created by its "execute" function, there's no relation to the form's contents except only within this function. And, interestingly, as of my observations, the statwrite call that occurs there takes places immediately when the form is closed and way before the layout variables are modified for a write back action that won't happen later. A third resort from the dilemma could be to introduce a call back into the filedialogxcontroller letting the form insert its own statwrite (and -read) function for these settings, which even would make the duplication of the pertaining variables expendable, also removing the neccessity to constantly assinging these values to and from their shadow copies. And now to the begging question: What Do You Think? Happy computing! -- (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-14 14:01:44
|
Hello Sieghard.
>I have a question concerning your extended filedialogx.
>I've run into severe problems with its statfile handling.
> It seems to me that saving the layout dependent settings simply cannot work.
Hum, sorry but I dont catch what you mean.
Here, with the "original" filedialogx, when you change the layout (and assigned a stat file for the component), it is saved.
Of course the position is saved too.
So, if you want to assign a custom position, imho, the easier is to use tfiledialogxfo.oneventloopstart() and change the position there:
Something like this (of course dummy code):
procedure tfiledialogxfo.oneventloopstart(const Sender: TObject);
begin
if container.optionposition = op_default then donothing() // the position of stat file will be used
else if container.optionposition = op_customposition1 then // a custom position will overwrite the position of the stat file
begin
left := customposition1left;
top := customposition1top;
end
else if container.optionposition = op_customposition2 then // a other custom position will overwrite the position of the stat file
begin
left := customposition2left;
top := customposition2top;
end
else // etc.
end;
But sureley I miss something.
Fre;D
|
|
From: Fred vS <fi...@ho...> - 2024-05-01 21:42:55
|
Hello Sieghard. I hope all is ok for you. About newdialogs: the position of the dialogs are much better now, many thanks for this great feature. But there is a problem with the tfilenameedit component that uses the new tfiledialog. You may try with MSEide, compile it using your newdialogs. Run Mseide and click on menu Settings/Configure MSEide. On edit MSEDIR, choose a directory clicking on the button-right + OK. The Settings window will close and the directory is not saved. Maybe you could take a look? There is also a discussion here (in which you are welcome to participate): https://github.com/mse-org/mseide-msegui/discussions/87 Have good times. Fred |
|
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-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-14 22:13:21
|
Hello Fred, you wrote on Tue, 14 May 2024 14:01:30 +0000: > Hum, sorry but I dont catch what you mean. Well, the matter IS a bit convoluted... I was probabely side-tracked and got lost a bit in the intircasies of statfile handling... > Here, with the "original" filedialogx, when you change the layout (and > assigned a stat file for the component), it is saved. Of course the Yes, I could reproduce that, and now I can also produce that with the working version (!) of my "newdialogs" filedialogx. But only if it's NOT called as a stand-alone form, yet. I WILL have to pursue this further, but I think the remaining problem can be solved. > position is saved too. So, if you want to assign a custom position, imho, > the easier is to use tfiledialogxfo.oneventloopstart() and change the > position there: Well, that's not the reason. My previous problem was caused by something quite primitive - in the course of testing different approaches, I had simply lost a function setting an arbitrary filename for the statfile, and kept trying to "convince" the code to save to the right file at several other places. Stupid attempts, but I missed the primary cause all the time. > Something like this (of course dummy code): Thank you for your attempt, but it's not needed to dig so deep. > But sureley I miss something. THe one who missed something was me in this case. But I still want to plea for a measure that obviates the, not just dupli-, but even multiplication of the layout state values (not just variables, as some of them are GUI elements) through the introduction of a call back from the form to the controller. This looks much cleaner to me, and it keeps the structure much closer to the original file dialog code. Still, there seems to be quite a bit of work to be done yet, but I will continue to get it running the way I want. Stay tuned! Best wishes for all your undertakings! -- (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-14 22:55:39
|
Hello Sieghard. I think that I understand better the problem (maybe). If you use a tfilenameeditx, via le Object Inspector, there is the property "statfile" where you can assign a config file. But the component tfilenameeditx himself uses also the filedialogxfo form who has also a property "statfile". So the trick is to assign to filedialogxfo the same "statfile" used by tfilenameeditx. I did try and in this case the layout is saved after close + run. I dont know if it is the problem that you related but yes, this could be a solution. Fre;D |
|
From: mohamed h. <me...@ho...> - 2024-05-07 18:06:48
Attachments:
Capture.PNG
|
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 |
Thanks for helping keep SourceForge clean.
X