Menu
▾
▴
mseide-msegui-talk
|
From: mohamed h. <me...@ho...> - 2019-08-01 16:29:36
|
Hi there Is it possible to setup the default propertie value of an object with an other value than fixed by the ide. Ex : changing automatically tdbgridwidget.cfo_captionfocus to true for all grids of the project . Regards. Med |
|
From: mohamed h. <me...@ho...> - 2023-09-28 10:10:14
|
Hello Fred, When a project PRJ is opened . The menu File—New--Form—Datamodule display the dialog: SELECT ANCESTOR !!! This does not happen in 4.6 Version. Med. |
|
From: Fred vS <fi...@ho...> - 2023-09-28 12:51:47
|
Hello Med. Even worst, here the menu is in Russian and each item shows ANCESTROR. I hope it is not a invasion... The good new is that it does not appear with ideU, there all is normal. Hum, very, very strange, thanks to note it. I will jump into it asap (I am super busy this week). Fre;D ________________________________ De : mohamed hamza <me...@ho...> Envoyé : jeudi 28 septembre 2023 12:09 À : General list for MSEide+MSEgui <mse...@li...> Objet : [MSEide-MSEgui-talk] IDE Hello Fred, When a project PRJ is opened . The menu File—New--Form—Datamodule display the dialog: SELECT ANCESTOR !!! This does not happen in 4.6 Version. Med. |
|
From: Fred vS <fi...@ho...> - 2023-09-28 17:57:46
|
Hello Med. Could you try this: In menu Project/Project Options/Templates/New Forms/ Column "I" (Inherited)---> See it only "Inherited Form" is checked, if nothing is checked there is problem. Also check if DataModule is not checked. See here: https://github.com/mse-org/mseide-msegui/assets/3421249/c80f937a-7a57-45ae-8f96-2767f3a05810 Indeed a fix must be done, if nothing was checked. ________________________________ De : mohamed hamza <me...@ho...> Envoyé : jeudi 28 septembre 2023 12:09 À : General list for MSEide+MSEgui <mse...@li...> Objet : [MSEide-MSEgui-talk] IDE Hello Fred, When a project PRJ is opened . The menu File—New--Form—Datamodule display the dialog: SELECT ANCESTOR !!! This does not happen in 4.6 Version. Med. |
|
From: Fred vS <fi...@ho...> - 2023-09-28 18:04:39
|
Re-hello Med. Note that the trick of previous post works only during the session, once you close the project and re-load it, Datamodule is again after the item Inherited, and you have to open project option again. So yes it is a big bug and I need to jump into it (but not possible asap, sorry). ________________________________ De : mohamed hamza <me...@ho...> Envoyé : jeudi 28 septembre 2023 12:09 À : General list for MSEide+MSEgui <mse...@li...> Objet : [MSEide-MSEgui-talk] IDE Hello Fred, When a project PRJ is opened . The menu File—New--Form—Datamodule display the dialog: SELECT ANCESTOR !!! This does not happen in 4.6 Version. Med. |
|
From: Sieghard <s_...@ar...> - 2023-09-28 20:55:34
|
Hello Fred, you wrote on Thu, 28 Sep 2023 18:04:31 +0000: [ide "idiosyncrasy"] > So yes it is a big bug and I need to jump into it (but not possible asap, > sorry). Well, there are a couple more I'm afraid... But anyway, don't overturn, do your regular tasks first. Then, you might be able to deal with the other stuff better, like e.g. the inability of the degugging code to realize if a file containing a breakpoint IS already open when it encounters it, opens it a second time and then may complain that it cannot open the form file belonging to it - very annoying. The debugging code now is very delicate, it usually dies as soon as you set the mouse cursor on a complex construct, probabely containing multiple redirections, or it was with properties? I've managed to avoid that mostly now. And there are a couple constructs that compile right away, don't produce any kind of sign of an error, but simply don't work - I found that to be the case mostly for the "window.decorated<anything>" values. But, as stated above, don't hurry. The issues are mostly solved now, and the problems can wait some, until there's time to tackle them. Thank you for your good work, and 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...> - 2023-10-02 20:13:23
|
Hello Fred, you wrote on Sun, 1 Oct 2023 20:12:27 +0000: > I am busy to try your new dialogs. > I try them for project ideU because it uses nearly all king of dialogs. Don't hurry - DON'T, please! The "newdialogs" STILL are work in progress, and as I wrote before, I've not even yet tackled the "king of dialogs", "msefiledialog". I'm just about "scratching my head" what to do to tame this queer beast. > So I copied all the units of your newdialogs folder into the root > directory of ideU project. I did not copy the customed dialog-units that > uses variables shared with ideU. Hmm - I don't quite get what the last sentence should tell... > It is those units that are not copied: > msestringenter.pas > mseintegerenter.pas > mseshortcutdialog.pas > msefiledialogx.pas Ah, I think I get it - you wanted to make sure your customized units are used. This should be the case automatically when the ancillary units are kept in a subordinate directory in the unit search path; that's how I did it, and I didn't even notice that you had copies of the above mentioned units in your source directory. Nonetheless, I got it to compile and run, but indeed, I had to make a couple adjustments. > But I get error at compilation: > msedialog.pas(351,44) Error: (5000) Identifier not found "StatExt" Upps, well, yes, that's a not-so-minor ommission on my part - I had added a line "StatExt = ".sta';" in "kernel/msestatfile.pas", for use with the extended "statfile" option "sfo_useexename", and possibly commented out again - or, did I even upload the files, or just some patch information? > And also now in ideU source: > > projectoptionsform.pas(1717,30) Error: (5000) Identifier not found > "colordialogstatname" --> Pointing to > deletememorystatstream(colordialogstatname); Yes, this is s definition in the file "msecolordialog.pas" which was completely unused throughout all of the mseide-msegui files, so I commented it out. Indeed, I had to reenable it to compile your ideU, but I forgot to mention - or neglected to do so, because I didn't expect you to immediately try that out, too... > I apologize if you have already given note about this but I did not find > it in your previous mails. No, I didn't, and I appreciate when you tell me about the problems you encounter with your undertakings. That way, it should be easier and faster to get it all working correctly. So, thank you for your information, and I hope I could help you getting it all to run, as far as it has evolved. (Mind you, remember, it is not finished yet, not before the file dialog works!) Success, and have a good time! -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) ----------------------------------------------------------- Mit freundlichen Grüßen, S. Schicktanz ----------------------------------------------------------- |
|
From: Fred vS <fi...@ho...> - 2023-09-28 22:03:44
|
Hello Med. OK fixed in last commit (but the bug was already in 4.6 Version). Of course you will need to recompile mseide. (And I have to find time to do new binary release with all the fixes) Hello Sieghard. OK, I will check I will check this week end. Write you later. Fre;D |
|
From: Sieghard <s_...@ar...> - 2023-09-29 20:13:27
|
Hello Fred, you wrote on Thu, 28 Sep 2023 22:03:28 +0000: > Hello Sieghard. > > OK, I will check I will check this week end. > Write you later. Thank you. And if you need more information, please ask, so I can test for it and give you feedback. -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) ----------------------------------------------------------- Mit freundlichen Grüßen, S. Schicktanz ----------------------------------------------------------- |
|
From: Fred vS <fi...@ho...> - 2023-09-29 20:28:02
|
Hello Sieghard. > And if you need more information, please ask, Ha, ok, so here one: Did you try the debugger with ideU? I did change some code for launch-run the debugger. Maybe it is the way you like and I could some change in mseide too. Fre;D |
|
From: Fred vS <fi...@ho...> - 2023-09-29 20:47:17
|
Hello Sieghard. >the inability of the degugging code to realize if a file containing a >breakpoint IS already open when it encounters it, opens it a second time >and then may complain that it cannot open the form file belonging to it - Hum, I did not note this but I will try it soon. Thanks to note it. Fre;D |
|
From: Fred vS <fi...@ho...> - 2023-09-29 21:31:01
|
Re-hello Sieghard. I have try this: set break-points in different places of some units to do like ping-pong call. But here it does not open new tabs of already opened units, it uses the already opened. And if a unit is not yet opened, it opens one it only once. But maybe I did not understand your request, so please explain (I did try it with ideU, not yet with mseide). ________________________________ De : Fred vS <fi...@ho...> Envoyé : vendredi 29 septembre 2023 22:47 À : General list for MSEide+MSEgui <mse...@li...> Objet : Re: [MSEide-MSEgui-talk] IDE Hello Sieghard. >the inability of the degugging code to realize if a file containing a >breakpoint IS already open when it encounters it, opens it a second time >and then may complain that it cannot open the form file belonging to it - Hum, I did not note this but I will try it soon. Thanks to note it. Fre;D |
|
From: Sieghard <s_...@ar...> - 2023-09-30 23:59:32
|
Hello Fred, you wrote on Fri, 29 Sep 2023 21:30:45 +0000: > like ping-pong call. But here it does not open new tabs of already opened > units, it uses the already opened. And if a unit is not yet opened, it > opens one it only once. > > But maybe I did not understand your request, so please explain (I did try > it with ideU, not yet with mseide) That latter point may be the cause of your inability to reproduce the problem - it may just not exist with ideU. I usually use the original mseide for tracing and examining breakpoints, or adjusting gui elements (which is not simple to perform outside the ide). The reason I don't use your ideU is that I just don't have one compiled all the time, as I used it a lot for testing some time ago and usually remove the test remnants when no longer needed. Otherwise, I usually compile a project from a terminal command line, using the "make" script I already sent you (although slightly revised by now). But I do need an ide for modifying or building a graphical layout, and that's why I keep the original mseide available, never modified from the distribution version. (I realize there is a utility to rebuild a _mfm.pas file when the .mfm has changed, but I'm not sure whether this still works correctly, and then I still had to integrate it into the "make" script.) You wrote on Fri, 29 Sep 2023 20:27:52 +0000: > Hello Sieghard. > > > And if you need more information, please ask, > > Ha, ok, so here one: Did you try the debugger with ideU? As I wrote above, no, not before. But now I tried. Well, and failed, at first. A couple errors on compile - compilation didn't like to use my "newdialogs", and dialogs weren't available, because I had put them aside for my tests. After that, It didn't compile because of an incompatibility with the "fontlist" unit. I had to add a "mclasses" to your "complang.pas" file. But that may only have been neccessary because of the probabely old version 2.8.4 I've still laying around. And then, I tried to build a project with your ideU. The first time ever I did that. Compilation failed again, because now it tried - of course - to use the standard dialogs instead of the "newdialogs" used for the project. Well, compatibility... that's still work in progress, after all. Just a minor grieve. At the second attempt, compilation went through, and the application - MSEclock - ran. I had prepared two breakpoints, one in the main unit and another one in the modified "msedialog" unit, which was therefore loaded in the editor To test the breakpoint function, I then activated the code triggering them, and they did show correctly. But the ide did NOT just reuse the open unit file, as you wrote, instead it opened it a second time, just not complained about something missing. Or did it? Well... I can't say for sure, but when I then tried to continue the application execution, the whole ide HUNG. No more activity, But after some trying, I found a hint: the window manager window list showed an entry hinting at a message to be dismissed, but nothing was to be seen on the screen. Only after some moving windows between desktops, a window saying "not decorated" showed up... This seems to have been the culprit, but I can't tell you for sure anymore. I had left the arrangement on the working desktop while I wrote this message, but just when I wanted to continue and assert the "not decorated" message, there was a flurry of window activity, and then - the whole arrangement was gone, the ideU just showed a bland main window, and I cannot now tell you anything whether the application would have continued to work or whatever else might have happened... But still, I have a suspicion what might trigger the multiple unit file openings: could it be that this happens when the pertaining unit file has been opened BEFORE starting the application, or perhaps even before compiling it? Unfortunately, the accompanying mishaps didn't allow a clean view of the course of events, so I will have to retry - later, though. > I did change some code for launch-run the debugger. > Maybe it is the way you like and I could some change in mseide too. It will take me "a bit of time" to find out. But I will pursue the case, and I will report what I can find. I hope that next time I will be more successful. Thank you for your consideration, and have nice 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...> - 2023-10-01 00:22:53
|
Hello Sieghard. There are binaries of ideU here: https://github.com/fredvs/ideU/releases/ You dont need to compile it to test the debugger. But of course if you want compile ideU with your new dialogs units, maybe it will be a few tricky because in ideU source there are also custom dialogs units. Have a perfect we. Fre;D |
|
From: Sieghard <s_...@ar...> - 2023-10-01 18:13:26
|
Hello Fred, you wrote on Sun, 1 Oct 2023 00:22:40 +0000: > There are binaries of ideU here: > https://github.com/fredvs/ideU/releases/ Yes, ok, I already took the source. > You dont need to compile it to test the debugger. > But of course if you want compile ideU with your new dialogs units, maybe > it will be a few tricky because in ideU source there are also custom > dialogs units. I DID recompile it (version 2.12.0 now), and even threw my "newdialogs" at it, and it compiled right away, and runs ok, on first glnce, at least. Well, not so much ok, though, as it DOESN'T want to keep the font size setting. Others too? It stupendously insists at always coming up with a huge 17 point (?) default font, although I didn't attempt to change the font yet. But that's a minor grievance only. Amendment: I just found that _disabling_ the setting for the "Suggested font height: 17" _does_ obey a saved font height. I suggest presetting that as "unchecked". Concerning the main pronlem I reported, the observations presented in my last message do hold: if a unit file had been opened before, e.g. for setting a breakpoint within there, the ide WILL reopen it a second time when the breakpoint is triggered on a subsequent run. Your ideU just does not complain about not being able to also open the form, at least when no form was shown before. Towards the stability of the debugger connection: I didn't test it a lot yet, but very soon stumbled over a not formerly seen phenomenon. Trying to have it show various variable values, I hit the name of an externally defined constant string (the "StatExt" from "newdialogs/msedialog.pas"). And it died, reproducibly, after a short delay. On the other hand, with the ideU, the debugger seems to be more stable indeed. Although I did have a glitch where it died on a complicated expression (FindText.dropDown.ValueList.asArray, to set the contents of a history list), I could not reproduce it a second time, so this might have been caused by something different I did. So, so far the results look like this: - Your ideU version 2.12.0 compiles correctly even with the "newdialogs". - It IGNORES any previous font setting, if that's not explicitely disabled. - It still places message windows (the "about" form, e.g.) at random spots sometimes, where they might be hard to see, especially below other windows. This might cause a situation where the ideU seems to hang. - "Some" dialogs (it happened to me on the project save dialog) have bad formatting problems - an overly long line gets broken up to be rendered behind the dialog's buttons. - The debugging code can die on certain conditions, like trying to access an externally defined constant. - Otherwise, the debugging code seems to be more stable than that of the original ide, although this couldn't be thoroughly tested yet. I hope that this might be of some use to you and help you to make your ideU even better, although I probabely will stay with the original ide or just my simple "make" script, because I simply don't need and thus not use most of its features. Thank you for your consideration, and have a good time. -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) ----------------------------------------------------------- Mit freundlichen Grüßen, S. Schicktanz ----------------------------------------------------------- |
|
From: Fred vS <fi...@ho...> - 2023-10-01 20:12:52
|
Hello Sieghard.
I am busy to try your new dialogs.
I try them for project ideU because it uses nearly all king of dialogs.
So I copied all the units of your newdialogs folder into the root directory of ideU project.
I did not copy the customed dialog-units that uses variables shared with ideU.
It is those units that are not copied:
msestringenter.pas
mseintegerenter.pas
mseshortcutdialog.pas
msefiledialogx.pas
But I get error at compilation:
msedialog.pas(351,44) Error: (5000) Identifier not found "StatExt"
And also now in ideU source:
projectoptionsform.pas(1717,30) Error: (5000) Identifier not found "colordialogstatname"
--> Pointing to deletememorystatstream(colordialogstatname);
projectoptionsform.pas(2227,43) Error: (5000) Identifier not found "colordialogstatname"
--> updatememorystatstream('colordialog', colordialogstatname);
I apologize if you have already given note about this but I did not find it in your previous mails.
Fre;D
|
|
From: Sieghard <s_...@ar...> - 2023-10-03 00:13:28
|
Hello Fred, now I can refine the conditions when the debugger dies some more: it does that reproducibly when you hit an uninitialized variable with the mouse pointer. (And it seems to see externally defined constants as uninitialized as well.) And, BTW, a question & suggestion: might it be advised to change the now CONSTANT definition of a "StatExt" preset to an initialized variable, so users can change it to another value (e.g. ".ini") if they want? Apart from that, 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...> - 2023-10-05 11:37:42
|
Hello Fred, in continuation to my previous "complaints" abour the functioning of mseide's debugger function (last one from Tue, 3 Oct 2023 01:55:52 +0200), here's some more information. Main problem is: It's even worse than what I wrote before. And there's obviously NO difference between the original mseide and ideU, except that (AFAIR) ideU does not complain when a form file is loaded multiply. Apart from that, source (and the companion form) files are always loaded when a breakpoint has been hit, even if the file was open even before. Only when such a file was opened by the debugging processs itself it may not be loaded multiply. But sadly, there's even more: the same problem applies to compiling, i.e. when the compiler hits an error in such a file, it will ALSO load it another time, and, at least concerning mseide, will complain about an already open form file. Concerning the debugger dying, apart from uninitialized variables and external constants, it also dislikes any instantiation of msestringarty variables, and possibly all of the ...arty kind as well. I've not investigated whether there's special code involved for handling the fpc open array types, but if so, this is certainly not able to handle these ...arty types then, and so the debugger simply gives up, ending the current session annoyingly prematurely. Sorry for this bad news, that's what I just hit when trying to get the msefiledialog working in conjunction with the "newdialogs" structure. It's - mostly - working now, but I'd like to have it working also with your extended "msefiledialogx", which shares a lot of code with the original source. In fact, I already had set out to extract the common parts and put them into a separate unit, but this was for an older, outdated, version. I'll notify you when I uploaded these units, hoping to find someone to further test (and possibly refine) them and get feedback about remaining errors and problems. But in any case, keep up the good work and don't let you get discouraged! Thank you very much! -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) ----------------------------------------------------------- Mit freundlichen Grüßen, S. Schicktanz ----------------------------------------------------------- |
|
From: fredvs <fi...@ho...> - 2019-08-01 23:33:17
|
Hello Med. Sorry but I did not find tdbgridwidget. Are you talking about tdbstringgrid ? For setting cfo_captionfocus to true by default there is in msewidgets.pas: const defaultcaptionframeoptions = []; You may change it as: const defaultcaptionframeoptions = [cfo_captionfocus]; But I do not understand how you want to change this with the ide. You may use the ide and right-click on the object and click on "Show as text". Then, by code set the default property like you want. But maybe I did not understand ok. Fre;D -- Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/ |
|
From: fredvs <fi...@ho...> - 2019-08-01 23:51:25
|
Re-hello. If you want the change only for one project, just copy msewidgets.pas with the changes into the main directory of your project. Fre;D -- Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/ |
|
From: mohamed h. <me...@ho...> - 2019-08-02 21:09:33
|
Hi fredvs, In fact I am talking about tdbwidgetgrid. Show as text displays all objects of that form and I want cfo_captionsfocus of all object in the project. I believe that setting defaultcaptionframeoptions = [cfo_captionfocus] is the only solution as you said. Thank you. Regards Med. ________________________________ De : fredvs <fi...@ho...> Envoyé : jeudi 1 août 2019 23:51 À : mse...@li... <mse...@li...> Objet : Re: [MSEide-MSEgui-talk] IDE Re-hello. If you want the change only for one project, just copy msewidgets.pas with the changes into the main directory of your project. Fre;D -- Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/ _______________________________________________ mseide-msegui-talk mailing list mse...@li... https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk |
Thanks for helping keep SourceForge clean.
X