Recent

Author Topic: The "Enable DWARF" dialog - before starting the debugger.  (Read 4516 times)

Arioch

  • Sr. Member
  • ****
  • Posts: 414
Re: The "Enable DWARF" dialog - before starting the debugger.
« Reply #30 on: September 19, 2022, 07:42:03 pm »
no Martin, they meant that that all RadioButtons had to be removed, and inserted as Buttons insetad (AKA CommandButtons)

i believe one-click is BAD goal, but whatever

at least in Delphi you also would have to include tfUseCommandLinks flag, otherwise you would again end with a smimilar ultra-wide kind of dialog we started with

also, like said above, ControlButtons had to be empty set

but the biggest issue for now i believe would be inability to link to Help because LCL TaskDialog did not implemented events but one.

while you can implement it i believe it would be re-inventing the wheel and the better course would be to find a better implementation. Hopefully mORMot, coming from Windows, did more complete implementatoin, and given compatiblie license (hopefully) they can be asked to donate.

Here is XE2 component copied, but converting clipboard DFM to LFM or to Pascal source shold not be hard

Code: Pascal  [Select][+][-]
  1. object TaskDialog1: TTaskDialog
  2.   Buttons = <
  3.     item
  4.       Caption = 'DebugInfo Format #1'
  5.       ModalResult = 201
  6.     end
  7.     item
  8.       Caption = 'DebugInfo Format #2'
  9.       ModalResult = 202
  10.     end
  11.     item
  12.       Caption = 'DebugInfo Format #2'
  13.       ModalResult = 203
  14.     end
  15.     item
  16.       Caption = 'DebugInfo Format #4'
  17.       ModalResult = 204
  18.     end
  19.     item
  20.       Caption = 'Run with no debugger'
  21.       CommandLinkHint =
  22.         'If you continue running without Debug Info selected - the debugg' +
  23.         'er would not be enabled, and this question would reappear next t' +
  24.         'ime you run your application.'
  25.       ModalResult = 100
  26.     end>
  27.   Caption = 'Running your application with debugger'
  28.   CommonButtons = []
  29.   Flags = [tfEnableHyperlinks, tfNoDefaultRadioButton, tfUseCommandLinks]
  30.   FooterIcon = 3
  31.   FooterText =
  32.     'This choice can be later changed in Project Options / Compiler O' +
  33.     'ptions / Debugging window.'
  34.   HelpContext = 10
  35.   MainIcon = 1
  36.   RadioButtons = <>
  37.   Text =
  38.     'Debugger can only run your application when it was compiled with' +
  39.     ' Debug Information enabled. <a href="https://forum.lazarus.freep' +
  40.     'ascal.org/index.php/topic,58745.0.html">Click here for more info' +
  41.     '.</a>'
  42.   Title = 'Choose Debug Information format'
  43.   Left = 504
  44.   Top = 272
  45. end
  46.  

As for pre-selecting radio-button i don't mean this is on the table.

1) it would require serious rework of infrastructure to communicate the available choices and the best choices ot the dialog.
In short term - that is not there. We can just do fast drop-in replacement to what is there already.

Frankly, once-click vertical-aligned pushbutotns-only dialog is as close to drop-in  as possible.  In this your team peers are spot on.

2) and when you do - in long term - this dialog would probably be no more needed and be removed

zamtmn does have a point. If Lazarus does know what thebest choice is - do not preselect the radiobutton, just update project options and do not bug novices
« Last Edit: September 19, 2022, 07:48:42 pm by Arioch »

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 8460
  • Debugger - SynEdit - and more
    • wiki
Re: The "Enable DWARF" dialog - before starting the debugger.
« Reply #31 on: September 19, 2022, 08:25:18 pm »
You can mix the button and the radio

Either

- radios for various debug info / default selected
- button (in main part of dlg)for without debug

OR
- radios for various debug info / default selected
- run without in the button panel, but "run / debug" instead of "ok"

Just making sure the main action to run with the debug info is not put into shadows by a more visible "run without dbg" button next to it.

---
It was established the help button can be used....



Arioch

  • Sr. Member
  • ****
  • Posts: 414
Re: The "Enable DWARF" dialog - before starting the debugger.
« Reply #32 on: September 19, 2022, 08:49:45 pm »
You can mix the button and the radio
Just making sure the main action to run with the debug info is not put into shadows by a more visible "run without dbg" button next to it.

I believe the mixed dialog at https://forum.lazarus.freepascal.org/index.php/topic,60624.msg454194.html#msg454194
is exactly th example how button overshadows radiobuttons, and it can not be helped

i believe it is wasting effort now

- You team peers believe in one-push approach,
- the existing right now infrasturcture does not provide for pre-selectin (or does it ?)
- after the infrastructure get evolved and generalized - there is big chance this dialog would be outright removed

So, make the simplest possible drop-in with array of vertical "command buttons" and with no "OK" and 'Cancel" buttons at all in the low panel of standard buttons. Okay, maybe with a single "Abort" button doesn there.

It is fast, simple, fits as drop-in replacement, and is what your peers prefer. Seems a bingo.

Would anyone ever provide help to the dialog, before this dialog removed at all? Then he would patch TTaskDialog to have it, or would take more developed component.

Quote
It was established the help button can be used....

What it means? You were given green light to add it? Or you were promiced it can be added ?

There is NO such "CommonButton", everyone went Internet and Microsoft discarded it, instead urging to provide hyperlinks.  Twice so since you can have only one Help button but multiple links.

You can add custom Command Button indeed - but... Then it still will close the dialog EVEN if you set zero ModalResult.
Non-modal buttons in modal dialogs are considered harmful :-D And honestly, MS has a point here.

Arioch

  • Sr. Member
  • ****
  • Posts: 414
Re: The "Enable DWARF" dialog - before starting the debugger.
« Reply #33 on: September 19, 2022, 08:53:00 pm »
or just re-enable closing the dialog with Esc or [ X ] - and that would be your "abort" options.

Include( Flags, tfAllowDialogCancellation )


Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 8460
  • Debugger - SynEdit - and more
    • wiki
Re: The "Enable DWARF" dialog - before starting the debugger.
« Reply #34 on: September 19, 2022, 09:08:13 pm »
You can mix the button and the radio
Just making sure the main action to run with the debug info is not put into shadows by a more visible "run without dbg" button next to it.

I believe the mixed dialog at https://forum.lazarus.freepascal.org/index.php/topic,60624.msg454194.html#msg454194
is exactly th example how button overshadows radiobuttons, and it can not be helped
yes, sorry I missed we had that before. Looks good.


Quote
i believe it is wasting effort now

- You team peers believe in one-push approach,
- the existing right now infrasturcture does not provide for pre-selectin (or does it ?)
- after the infrastructure get evolved and generalized - there is big chance this dialog would be outright removed
It will be
- 1 new enum (listing the options)
- about 5 lines of code per backend (and some backends inherit, and don't need it)
  (if the backend has requirements / currently 2 of them)
- virtual in the base class

1) procedure declaration
2) procedure in implementation
3) begin
4) the value
5) end

Between 30 seconds and a minute per backend.

Have you looked at the current code calling the dialog, and where it gets the list from?

Code: Pascal  [Select][+][-]
  1. class function TFpDebugDebugger.RequiredCompilerOpts(ATargetCPU, ATargetOS: String): TDebugCompilerRequirements;
  2.  

Quote
Quote
It was established the help button can be used....

What it means? You were given green light to add it? Or you were promiced it can be added ?

It already exist in some dialogs, so its not a new concept, so it can be used here too.

Invoking help is done by the single line of code, I posted earlier.


Arioch

  • Sr. Member
  • ****
  • Posts: 414
Re: The "Enable DWARF" dialog - before starting the debugger.
« Reply #35 on: September 19, 2022, 09:28:56 pm »
Between 30 seconds and a minute per backend.

Have you looked at the current code calling the dialog, and where it gets the list from?

It already exist in some dialogs, so its not a new concept, so it can be used here too.

1. Ok, good if it is so. Rehash API and we'll see.

Sad point, i tried to cherry-pick your commits into Fixes_2_2 and got conflicts... Maybe because my Fixes_2_2 is dirty

2. No, like i said, fixing design first. I do not want to make elaborate work only for it to be discarded and said to be not-Lazarish. One time is enough. Agreement on design first, implementing later.
Besides i spent fair deal of braincells and time on LCL today debugging ActiveX failure with undocumented library.

3. The concept is not new, but it was deliberately removed from MS TaskDialog.
So, we are back to square one - either drop TaskDialog and design custom window, or drop Help button, that never was there to start with.

Personally i believe hyperlink is no worse to the button,  but LCL does not have them either. The sources clearly show they did not implement tdfEnableHyperLinks - it just is included to execute Delphi code unchanged, but does not work.

So, neither Help button nor hyperlinks in the task dialog.
If you need them - then make custom window instead.

P.S.  ...i should just had looked into LCL, lol

Code: Pascal  [Select][+][-]
  1.  
  2.  
  3. unit LCLTaskDialog;
  4.  
  5. {                            LCLTaskDialog.pas
  6.                             -----------------
  7.  
  8.  Implement TaskDialog window (native on Vista/Seven, emulated on XP).
  9.  This unit was originally a part of the freeware Synopse mORMot framework,
  10.  licensed under a MPL/GPL/LGPL tri-license; version 1.19.
  11.  
  12.     Synopse framework. Copyright (C) 2016 Arnaud Bouchez
  13.       Synopse Informatique - http://synopse.info
  14.  
« Last Edit: September 19, 2022, 09:31:43 pm by Arioch »

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 8460
  • Debugger - SynEdit - and more
    • wiki
Re: The "Enable DWARF" dialog - before starting the debugger.
« Reply #36 on: September 19, 2022, 09:33:52 pm »
It seems some of the discussed items are going in cycles now.

So maybe there are misunderstandings? If I did lack clarity somewhere then I am sorry for that.
Also to point out: Some of my later statements included (implied) withdrawals of prior questioning of ideas.

Also apparently for some items the separation of their context to the context of other items in the message where I introduced them (or even other messages), may not have been made clear enough. E.g. the question of the help button had been made based on the expressed assumption of mine that such a help button would be a new concept and was not yet present anywhere. I then found my assumption wrong (i.e., help buttons are already in use) and hence withdraw my concerns. The context of checking with the team had been as mentioned based on this being a fundamentally new concept, and that even though not explicitly mentioned had been discovered not to be the case. Again, sorry about this.



So to remove any doubt:

This https://forum.lazarus.freepascal.org/index.php/topic,60624.msg454194.html#msg454194
=> radio + one embedded "link button" for "run without dbg"

With the addition that one radio must be preselected.

The link to become a help button.

Is 100% ok.

I will merge/apply this.
No backsies on this.

As mentioned all captions must be initialized from resource strings (IIRC unit LazarusIdeStringConst)



I also stand by my prior word, that for this one patch/merge-request I will accept it against fixes branch, if it can be cherry picked to main without major merge conflicts. (tree conflicts/ chunks of more than a dozen lines conflicting)
It will very most likely only appear in the main branch.

I am happy to assist further with the help system, or the new debugger procedure, as soon as I see a first patch against actual IDE code (I.e. not just the form, but IDE code actually creating/calling that form.)


Hope that covers it.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 8460
  • Debugger - SynEdit - and more
    • wiki
Re: The "Enable DWARF" dialog - before starting the debugger.
« Reply #37 on: September 19, 2022, 09:42:50 pm »
overlapped with my previous post...

Sad point, i tried to cherry-pick your commits into Fixes_2_2 and got conflicts... Maybe because my Fixes_2_2 is dirty

Which commits? And cherry pick to where?
Normally all commits in fixes are in main, and where picked from there.


Quote
2. No, like i said, fixing design first. I do not want to make elaborate work only for it to be discarded and said to be not-Lazarish. One time is enough. Agreement on design first, implementing later.
Ok, then simply set the first radio to be the default.

Quote
3. The concept is not new, but it was deliberately removed from MS TaskDialog.
So, we are back to square one - either drop TaskDialog and design custom window, or drop Help button, that never was there to start with.
Ok here we have miscommunication.
I am missing completely what you mean?

Which concept?
And are we talking about the TTaskDialog in the LCL? (Which I hope (not tested) to work on all platforms....)
Or something else?


Quote
So, neither Help button nor hyperlinks in the task dialog.
If you need them - then make custom window instead.
Try a button and tfUseCommandLinks  with the LCL control.
At least on Windows that shows radios, and a flat-button-like




It seems the main missing issue is, that no one checked yet what will happen on other OS.

Arioch

  • Sr. Member
  • ****
  • Posts: 414
Re: The "Enable DWARF" dialog - before starting the debugger.
« Reply #38 on: September 19, 2022, 10:03:19 pm »
Which commits? And cherry pick to where?

i'll check tomorrow on vanilla Fixes_2_2, mine is polluted currently

Quote
Normally all commits in fixes are in main, and where picked from there.

I am not Lazarus hacker, not yet at least. I am user who contributes when he can.

Quote
Quote
3. The concept is not new, but it was deliberately removed from MS TaskDialog.
So, we are back to square one - either drop TaskDialog and design custom window, or drop Help button, that never was there to start with.
Ok here we have miscommunication.
I am missing completely what you mean?

Which concept?

concept of having non-modal HELP button in an otherwise modal TTaskDialog.

ANY button would close the dialog, even if ModalResult = 0

Quote
And are we talking about the TTaskDialog in the LCL? (Which I hope (not tested) to work on all platforms....)

Both. VCL dialog is wrapper over Windows Vista API
LCL dialog is wrapper over Vista API when it present, and re-imlpementation of SUBSET of Windows API otherwise.

This means, on Windows LCL dialog would look exactly as VCL or any other Windows-native.
BUT will miss some behavior functonality.

The pieces that mORMot did not re-implement in cross-platform way - they did not expose in API.

In particular that is hyperclick link - yes it is RENDERED on Windows, but it has noi any aciton to it, because LCL TTaskDialog did not implement the required events in x-platform way.
And implementing it in x-platform way would require limited HTML rendered inside LCL. Which would not happen soon.

So,

- non-closing HELP button would not be in Taks Dialog, because Microsoft deliberately precludes it.
- Hyperlink would not work in LCL TaskDialog, because it is not implemented.
- Even if hyperlink worked on Windows alone - it still would not be usable on non-Windows, so could not be relied upon
- Now, you can do a dirty trick: add the Help button, that would close dialog and then immediately show it again

Code: Pascal  [Select][+][-]
  1. Choice: TModalResult;
  2.  
  3. repeat
  4.    Choice := TaskDialog1.Execute();
  5.    if Choice <> mrHelp then exit;
  6.    // command to show LHelp or WWW help
  7. until false;

Would you want SUCH a hack?

If not - you have a binary choice.

Either give up on TTaskDialog, or give-up on help (button or hyperlink - both don't work) in the task dialog.
This - or that.

Arioch

  • Sr. Member
  • ****
  • Posts: 414
Re: The "Enable DWARF" dialog - before starting the debugger.
« Reply #39 on: September 20, 2022, 12:32:23 am »
All in all, if you want to extend TTaskDialog to make it x-platform - that is a noble goal, but i believe it is outside FpDebug scope.
Let's create a separate thread and talk there.

The immediate things would be

- reach Arnaud and ask if they gave up on Task Dialog or not. Is mORMot TaskDialog upstream or LCL is ? PErsonally i'd rather hack on mORMot with its Delphi compatibility, than FPC-only LCL. But in the end it is about "who is upstream now".

- persuade LCL team to include any simple fast HTML renderer into the core. We did not have to have fast and flexible solution, like thta commercial Delphi HTML components. We probaly would not even need as much as THtmlFrame. But ascending JediVCL HTML Label or something of equaly complexity would be called for.

D:\fpcupdeluxe\ccr\jvcl\run\JvCtrls\jvhtcontrols.pas
D:\fpcupdeluxe\ccr\jvcl\run\JvNet\jvhtmlparser.pas

Or anything similar. Google shows https://github.com/jackdp/DzHTMLText2 and https://laptrinhx.com/delphi-and-lazarus-html-label-component-4127787442/

Officially Microsoft only accepts HTML A-tag and nothing else. But implementing ad-hoc anchor-only parser, and then rendered to supplement it, should we really do it? https://learn.microsoft.com/en-us/windows/win32/api/commctrl/ns-commctrl-taskdialogconfig

This is probably worth doing, but the amount of time and energy to to make it ascend into LCL core would be.... substantial. Hence would be past the timeline you set to FPDebug enhancement. Albeit on its own merit that seems a worthy task.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 8460
  • Debugger - SynEdit - and more
    • wiki
Re: The "Enable DWARF" dialog - before starting the debugger.
« Reply #40 on: September 20, 2022, 02:09:07 am »
Quote
Which concept?
concept of having non-modal HELP button in an otherwise modal TTaskDialog.

Code: Pascal  [Select][+][-]
  1. procedure TForm1.TaskDialog1ButtonClicked(Sender: TObject;
  2.   AModalResult: TModalResult; var ACanClose: Boolean);
  3. begin
  4. end;
  5.  
Looks promising.

Tested on Linux and Windows, it works.
Not tested on Windows (nor Mac)

The other Issue => there is no build in "help" button. => and if the custom buttons where to go up into the main area => then how to get a help button.
Also that means there would be no way for a "help" button on the left side, with all other buttons aligned towards the right side.

Or did I miss something.


Quote
Quote
And are we talking about the TTaskDialog in the LCL? (Which I hope (not tested) to work on all platforms....)

Both. VCL dialog is wrapper over Windows Vista API
LCL dialog is wrapper over Vista API when it present, and re-imlpementation of SUBSET of Windows API otherwise.

This means, on Windows LCL dialog would look exactly as VCL or any other Windows-native.
BUT will miss some behavior functonality.

Tested under Linux. Mostly ok.
Only the buttons (if tfUseCommandLinks*) is set,  will always be above the radios.

Not yet looked at MacOs.

Quote
All in all, if you want to extend TTaskDialog to make it x-platform - that is a noble goal, but i believe it is outside FpDebug scope.
It may already be... With tiny differences/limits...


Quote
- reach Arnaud and ask if they gave up on Task Dialog or not. Is mORMot TaskDialog upstream or LCL is ? PErsonally i'd rather hack on mORMot with its Delphi compatibility, than FPC-only LCL. But in the end it is about "who is upstream now".
Even if, that will be a hold back. And I wont be able to mediate all of that.
Lets see how far we can get with what is there. Then lets see what needs adding.


Quote
- persuade LCL team to include any simple fast HTML renderer into the core. We did not have to have fast and flexible solution, like thta commercial Delphi HTML components. We probaly would not even need as much as THtmlFrame. But ascending JediVCL HTML Label or something of equaly complexity would be called for.
There is one for the IDE hints ...IPro... package
But same as above.


That might mean to defer the Help button => but the initial goal to reduce the width would be reached.
Also: a run without debug.

And even if the pre-select is not smart to begin, that will be easy to add, and help the user with the choice.


// Tests for Mac assumed to succeed.


PascalDragon

  • Hero Member
  • *****
  • Posts: 4758
  • Compiler Developer
Re: The "Enable DWARF" dialog - before starting the debugger.
« Reply #41 on: September 20, 2022, 09:50:05 am »
If anyone gets interested to evaluate their code and maybe copy it into LCL, then
https://github.com/synopse/mORMot/blob/master/SynTaskDialog.pas - "licensed under a MPL/GPL/LGPL tri-license; version 1.18"
https://github.com/synopse/mORMot/blob/master/SynTaskDialog.rc

Please note that this license is not compatible with the license used with the LCL cause the LCL uses LGPL-with-static-linking-exception, but mORMot uses the unmodified LGPL.

Arioch

  • Sr. Member
  • ****
  • Posts: 414
Re: The "Enable DWARF" dialog - before starting the debugger.
« Reply #42 on: September 20, 2022, 11:42:02 am »
If anyone gets interested to evaluate their code and maybe copy it into LCL, then
https://github.com/synopse/mORMot/blob/master/SynTaskDialog.pas - "licensed under a MPL/GPL/LGPL tri-license; version 1.18"
https://github.com/synopse/mORMot/blob/master/SynTaskDialog.rc

Please note that this license is not compatible with the license used with the LCL cause the LCL uses LGPL-with-static-linking-exception, but mORMot uses the unmodified LGPL.

Oh, way too many licenses out there...
But anyway, after i checked LCL sources belatedly, they already donated their to LCL. So, moot point from my part it was.

Now, i think TaskDialog talk here goes vicious circle.

Should LCL x-platformly re-implement missed HTML+hyperlinks funcitonality of TaskDialog? Maybe.But it is beyond FpDebug talk andis worth a separate backburner thread.

Should FPDebug use TaskDialog or custom one ? Depends whether adding "visible HELP button" functionality is required or "quick drop-in replacement" is preferred. Both are fine by me, but the choice has to be made by Team Lazarus.

Arioch

  • Sr. Member
  • ****
  • Posts: 414
Re: The "Enable DWARF" dialog - before starting the debugger.
« Reply #43 on: September 20, 2022, 11:46:52 am »
Quote
- persuade LCL team to include any simple fast HTML renderer into the core. We did not have to have fast and flexible solution, like thta commercial Delphi HTML components. We probaly would not even need as much as THtmlFrame. But ascending JediVCL HTML Label or something of equaly complexity would be called for.
There is one for the IDE hints ...IPro... package

"for the IDE" - irrelevant. TTaskDialog is for desktop user's apps, outside of IDE. Whatever new code TTaskDialog would use - would have to be moved to RTL/LCL/whatever core *runtime* packages end-user apps must use anyway.

The CanClose thing i missed, maybe indeed it can do

----

One more thing missed in LCL/mORMot rather that pure Win32 wrapper

« Last Edit: September 20, 2022, 04:49:42 pm by Arioch »

Arioch

  • Sr. Member
  • ****
  • Posts: 414
Re: The "Enable DWARF" dialog - before starting the debugger.
« Reply #44 on: September 20, 2022, 12:03:46 pm »
Default choice in "pushbutton" mode, native Win32, Delphi vs LCL

To me, Default rendering with CommandButtons is VERY faint, and is less pushy" then mere mouse-hover effect.
On the fence, whether that is good or bad thing.

Personally i am against default choices, so it is good.
But "pure one-click" solution would ask to get rid of radiobuttons at all and only use veritcally stacked pushbuttons, then "faint default" would be bad

Then again, the lack of extended hint in LCL is... disturbing.  I too kit for granted.
To me "Run no debug" without immediately visible extended hint seems a big loss.

 

TinyPortal © 2005-2018