Like i said, at least for today, i am Lazarus user not Lazarus hacker.
I am "eating my own dog food" and doing so hit my thumbs over things sticking out of Lazarus. Then i try to fix/report/workaround them.
This means i generally work with stable Lazarus, and if i want to look into some dusty corner, destabilizing it in process, i would do it in a limited, localized (as in locality, not locale) fashion.
You probably, over the course of years of your involvment, elaborated gut feeling which parts of Lazarus do what and how good. I don't have it. Trying to wrap my mind over some pieces inside LCL or IDe or FPC - i want to feel secure that all other parts are as stable as can be.
What future can bring - no one knows, up to WW3 and total sharding of once global internet to tightly secured blocks.
However, for now i am a user, of stable Lazarus, willing to contribute what i can and to extent i can, but not above it.
There is only so much of unstable, bleeding edge things one can handle. For now i think, erroneously or not, that Lazarus would be one too many for me.
> did make the dialog a local var. No need to burden the class with it.
i actually had a feeling you would do or demand it :-)
it is only a single pointer of a burden.
granted, the time penalty of creating/destroying is miniscule too.
i just did what i usually do, without having strong opinion about it
> - Add, fetching the default from the backend
implement a generic API shared by all the back-ends, it should not be hard
however... i repeat my opinion that this qould call for removal of the dialog. If back-end knows which format to set - just do it.
If you feel uneasy about covert data changed - ask user a yes/no (or actually ok/abort) question.
i believe
zamtmn was spot on here. If developer is newb - don't bug him with choices he can not make. The only think newbs need is a a single button "do me an all-round good". If developer is seasoned - inform him of the change done, or ask for permission to do. If he has opinion - he knows how to open and navigate Program Options. Both ways, this dialog is obsoleted as soon as back-end knows what it wants. It was a stopgap measure.
Well, maybe "apply default" / "cancel run" / "abort run and open Project Options" is the best possible choice for user.
> - include the check/change for the "external info" flag
this sounds a creeping featurism to me. We would end sucking in the whole Project Options / Debug panel. But it already exists.
Frankly, it feel like you grow more emotionally attached to this dialog than i was. This was always a stopgap before "debugging infrastructure knows better", which was the correct solution. If you implemented the latter, the dialog "outlived its usefulness".
> - fix, that the dialog is also shown, when the debug-info is switched off entirely
with the phrase like that i am always lost, what is (bad) observed behavior, and what is (good) goal.
is it that a dialog is shown and it should not be? or the opposite?
as for the correct design from user's perspective, i believe it should be this way:
1. The project starts with either undefined (NULL in SQL terms) back-end, or with "default" all-round good backend pre-selected. Again, if IDE knows what back-end and what format are soft spot for today - just use that knowledge. Laz devs know it, newb doesn't. Asking newb would bring nothing except F.U.D.
2. The explicit "no debug info" either is different state than "undefined", or there is no "undefined" at all (the new project always pre-selects most good format and back-end)
3. there can be however a case, when there was a good match of info format and backend, then the user changed back-end, and the new back-end can not consume the priorly selected format. THAT is the case i believe the prompt is warranted.
4. when a "no debug info" was explicitly selected - the correct behavior would be not to show a prompt, but to make debug-related funcitons fidabled in IDE
Well, here is when you can throw "don't bother newbs" back at me.
VCL (and probably LCL) does not provide for making a control disabled, yet with explanation WHY disabled. Even .ShowHint in VCL is ignored on disabled controls.
Still my gut feeling is that having "Run with debug" "Step in" and similar actions diabled would be better choice.
did you notice how we are sliding into spec-making, BTW ? oh, okay, techwriting sucks, i know :-)
Add "help" to the footer buttons (like ok,cancel) - requires non-native dialog
No it does not.
I always did screenshots from the same Windows machine, and it rendered all four horizontal buttons (help, run no debug, ok, cancel) in native Win7 dialog.
(allows to move "run without" up into the main part of the dlg)
Now this IS impossible, but it is a different thing.
It seems exactly what i asked about yesterday, in the post wit hthree screenshots. « on: 2022-09-20, 18:19:45 » - refresh those questions and screenshots please.
TaskDialog operates either in "command buttons" mode or not.
In commands button mode all buttons are large, vertically arranged, have (sadly not in LCL) two captions (or, in other words, caption and immediately rendered hint). There is no panel to have "horizontally-arranged ubttons", or should not be.
In non-c-b mode, all buttons are small, horizontally aranged, and have no hints. But then there is no "big buttons"
In the API it is one and the same "array of butotns" that is being arranged horizontally or vertically.
----
Surely you can extend the dialog to break out of Microsoft guidelines, and add whatever customization. But that would be designing custom window, that you IDE team decided against.
If you want to switch to vertical alignment - it takes a single line change, about Flags property.
If you want to have vertical alignment for "run no debug" yet a separate HELP widget - then it should be HTML-esque "link".
If you to modify TTaskDialog anyway, for implementing non-standard "split buttons" mode, it feels better to invest into implementing standard "hyperlink" mode instead.
Add a checkbox (as is avail in the dialog) to modify the "project template". So new projects will have the chosen setting too, and not show the dialog.
I would need to search myself, where that code is ....
The code should be simple, just put the checkbox caption into TTaskDialog.VerificationText sting property. After mrOK execute - check .Flags for verificaiton-something
The problem - i think google told me there is or was a bug, that made the state of that checkbox not returned into TTaskDialog.Flags and people were looking for a work-around.
This may be false memory about a different problem, or a bug fixed long-ago. But beware.
Recent
