Ths shoots down the whole "extend generic dialog" idea :-)
Don't get that wrong, that is my opinion. I don't single handedly make all the decisions. There is team that I am part of.
Okay, let me be verbose then
.
This idea is too general for the scope of this topic, enhancing debugger GUI. So in the context of this thread - it is dead on arrival.
By "standard generic dialogs" you probably meant CreateMessageDialog and friends.
https://lazarus-ccr.sourceforge.io/docs/lcl/dialogs/createmessagedialog.htmlThey were borrowed from Delphi, and they have a pretty standard layout that dozens of programs are using for decades.
Changing their layout - and doing so departing from Delphi's behavior and from expectations of all the lagayc rpojects developers - is not an easy step. It can not be made in the "enhance debugger" thread.
Maybe the team as whole would decide to re-style LCL and IDE, maybe not, but it is out of this scope.
For the purpose of this topic, and change in standard dialogs is change of style we can not do on our own, and for the narrow purpose of this topic - that idea is dead.
---
...there needs to be an LCL implementation for all platforms.
The project used stock VCL controls to implement it on non-Vista systems, i believe it uses stock LCL controls now. Otherwise why have {$ifdef FPC} inside.
But if you really want to spend toyr time - you can download that unit and check yourself. I think it was a stand-alone one and could work without reest of mORMot lib, or at least without most of it.
The license was Mozilla or LGPL or something.
And my recurring topic for you, is that questions even unresolved have their own merit, so thees notes of "problem that would arise if we go this way" better be written down in ome easy to stumble-upon place.
In an ideal word, I would agree...
In this world, in which there is way to often not even time to write down doc for existing things...
I did provide details on the implementation...
[/quote]
And i re-iterate too. I do not say "make new texts", i say may the texts you ALREADY wrote here and there persist, don't make the effort you spent writign extensive explanations in forum or tracker potentially get wasted, as geological residue. That was always my point, not "make new docs" but "make sure the quasi-docs you already made will float"
I joined the project to write code for certain features. I am nowadays doing way more than that.
That's how it happens. When RxLib died they officially donated to JediVCL, so i learned of it. I tried it on my Delphi 5 - and despite docs it did not work that well. I went their NNTP forum - and they said "ooops, bug in documentation. None of thus have D5 and it is no more supported". And i was like "NOOOO! don't!!!" - and then it was several years of my doing that "don't" :-)
RadioGroup
A listbox might be look well too. It may be closer to the MS-dialog, since the entire selected row is highlighted.
styling a la MS-dialog is not the goal as of yet. And RadioButtons convay "you can select only one" much better than more generic listview
Another quesiton if there also should be a HELP button, launching user, for example, into that sticky forum thread, unleast something better made?
Initially I thought "if nothing else in the IDE has them..." But actually some forms do. So, help button is fine.
But where the Help button has to be then? I do not remember those windows, i just was mimicking LCL TButton Panel
I wish LCL TStaticText could marry autosize and multi-line text (WordWrap) as JediVCL's one can...
Don't label do?
I'll check later, indeed. I put the StaticText as i was expecting to use its built-in borders. But i did not in the end, so no reason not to change it to simple TLabel indeed.
from my opinion:
"Please choose ... otherwise it will run without debugger"
That paragraph should go.
The top banner is... verbose indeed. But there still would be a need to make it clear to novices what they are expected of, and what they can expect
There can be a radio for "run without", but a choice must be made, or it will "abort" / not run at all. (Hence no "Ignore" either)
With this approach i don't like that the sole negative option would get mixed in positive options and would be visually indifferent form them.
You won't believe, i was even thinking about patching TRadioGroup, so it would treat an empty line as a command to insert visual separation rather than an anonymous button.
With horizontal menu there is "from now on - stick to the right window edge" flag. I want something similar then between positive and negative actions.
We can drop RadioGroup and instead use a panel and create checkboxes in runtime instead, but then we would loose simplicity of "Anyway the kind of control is easily exchangeable." and the lingua franka of populating formats via "Control.TStrings.Assign(source.TStrings)"
It can be reimplemented adding a TStrings property to the form, but the boilerplate would be significant. Maybe it would be worth doing after finalizing design, but not before.
Alternatively "Run without debugger this time" can be a checkbox below the radiogroup...
Sweet thing about removing Ignore button is that TButtonPanel cna be used then
And IMHO, the vertical spacing between the radio items it to much....
I want to make this dialog generic, so it would not be pixel-sized to have exactly 4 lines in the radiogroup. I expect it to be reused by all debugger back-ends, in that "intersection of sets" fashion.
I also do not want to implement elaborate auto-sizing for it. I am not sure i just can set AutoSize to the RadioGroup and to the form - and it would be automagic on all the platforms and all the font sizes. At least in Delphi autosizing rarely works reliably.