PeterPanettone

That's why I love PROGRAMMING: It's ABSOLUTE FREEDOM as opposed to the old [political terms removed by OP] rule.

BTW, I wonder why something useful like this is not natively BUILT-IN. TCheckListBox should have a boolean property HideValues which does exactly what Mahdi's code does.

5 minutes ago, aehimself said:

In a more advanced project (especially after a UI change or refactoring) you'll quickly realize why separating the UI and data storage/handling extremely important.

In your example, let's say a user doesn't like CheckListBox and wants you to change it to something else. Apart from the visual changes, you'll have to re-code your business logic as well.

Generally, you are right. But in this particular case, it's more a prototype feature/application.

3 hours ago, aehimself said:

I don't feel fine storing information in the UI.

That's what I call "user-centric" programming. 

And BTW, the stored information is HIDDEN by using the code of @Mahdi Safsafi

12 hours ago, Mahdi Safsafi said:

set Style to lbOwnerDrawFixed and owner draw your control:

Thank you for your code! It's much appreciated!

In Delphi 10.4, I fill a TCheckListBox in a loop adding name= value pairs:

for i := 1 to 32 do
  CheckListBox1.Items.AddPair(GetName(i), GetValue(i));

Of course, the CheckListBox then shows:

Quote

Name1=Value1
Name2=Value2
Name3=Value3
etc.

Well, is there a "trick" to show only the NAMES and HIDE the VALUES in the CheckListBox?

I would like to avoid AddObject or messing around with multiple string-lists.

Any idea?

18 minutes ago, Mahdi Safsafi said:

@Stefan Glienke IsType<x> does not distinguish between distinct-type. And it could be a source of error. Using Overloaded function in some how can distinct at least if you specify the type explicitly:

type TMyString = type string;
procedure DoSomething2(const AParam: Integer); overload;
begin
  Writeln('this is a integer :', AParam);
end;

procedure DoSomething2(const AParam: string); overload;
begin
  Writeln('this is a string :', AParam);
end;

procedure DoSomething2(const AParam: TMyString); overload;
begin
  Writeln('this is a TMyString :', AParam);
end;

var
  a: Integer;
  s: string;
  m: TMyString;

begin
  s := 'string';
  m := 'mystring';
  DoSomething(a);
  DoSomething(s);
  DoSomething(m);

  DoSomething2(a);
  DoSomething2(s);
  DoSomething2(m);
  Readln;
end.

 

 

Really nice code!

However, your employer has to pay for the time you need to write overloaded code. (Though I assume you're a fast writer).

54 minutes ago, Remy Lebeau said:

Just use Generics for this (see Testing the type of a generic in delphi), eg:

type
  TSomeClass = class
    class procedure DoSomething<T>(const AParam: T);
  end;

class procedure TSomeClass.DoSomething<T>(const AParam: T);
begin
  case GetTypeKind(T) of
    tkUString: begin
      ShowMessage(PUnicodeString(@AParam)^);
    end;
    tkInteger: begin
      ShowMessage(IntToStr(PInteger(@AParam)^));
    end;
  end;
end;

 

Nice professional code, compliments!

But why making something so complicated and prone to errors, if it could be SO EASY with Open Type Arrays?

2 hours ago, Uwe Raabe said:

Well, it could split that code and put the pieces into the appropriate overload.

Why make double work? The employer would like it if you need only half the time.

Today in the shower I had an idea - wouldn't Open Type Arrays be a useful thing?

What if we could write:

procedure DoSomething(const AParam: [string, Integer]);
begin
  if AParam is string then
    ShowMessage(AParam)
  else if AParam is Integer then
    ShowMessage(IntToStr(AParam));
end;

One could argue that if we want flexibility we could use overloaded procedures.

But if we have procedures with many different parameters then we had to write a lot of overloaded procedures - Open Type Arrays would simplify things a lot.

What do you think?

1 hour ago, haentschman said:

programming a own MessageDialog

Very nice. Do you also make your own INPUT dialogs?

The EXCELLENT Rejbrand Input Dialog Box:

https://specials.rejbrand.se/dev/classes/multiinput/readme.html

is automatically centered on the form. Very nice!

One could argue that positioning a message dialog in the middle of the screen is the default behavior in Windows. But from my point of view, that argument is from the prehistoric time when monitors still had the size of a postage stamp. Today, more and more people use large (if not huge) monitors. Therefore, if an action is performed with a control on a form and that action leads to a change on the form (so the user's attention is focused on the form), centering a message dialog on the form would be a better user experience.

Each Application.MessageBox, MessageBox (MessageBox API), MessageDlg show the dialog in the center of the SCREEN.

Is it possible to have any of them centered on the Application Form?

In Delphi 10.4, is there a way to increase the narrow space between the TCheckBox glyph and the checkbox caption text?

The WordWrap property of TCheckBox is set to True.

BTW, the demos have issues with non-existing project icons. I resolved them by assigning the default icon in Project Options. Maybe you should fix this at Github.

37 minutes ago, Anders Melander said:

• Open DragDropDR103R.dpk (the run-time package)
  Save as DragDropDR104S.dpk
  Compile
• Open dclDragDropDR103R (the design-time package)
  Remove DragDropDR103R from requires and add DragDropDR104S instead.
  Save as dclDragDropDR104S
  Compile and Install.

That worked, with these exceptions:

1. "Save as DragDropDR104S.dpk": you cannot save it directly as DPK. You must save it as DragDropDR104S.dproj which implicitly creates the DragDropDR104S.dpk.

2. There are a few typos in the original source. You should fix it at Github:

Typos:

Fixed:

It would be nice if Embarcadero would create a 10.4 version for GetIt.

Does anybody know a Drag and Drop Component Suite version for Delphi 10.4 Sydney?

https://github.com/DelphiPraxis/The-Drag-and-Drop-Component-Suite-for-Delphi

The latest version on that page is for Delphi 10.3 Rio.

I tried to install it on Delphi 10.4 Sydney by using the Delphi 10.3 Rio package, but this error didn't allow me:

[dcc32 Fatal Error] DragDropDesign.pas(38): E2213 Bad packaged unit format: ..\Library\DX103R\Win32_Release\DragDropDR103R.dcp.DragDrop - Expected version: 34.0, Windows Unicode(x86) Found version: 33.0, Windows Unicode(x86)

But that dcp file is a binary file and cannot be edited.

Does anybody know an existing version for Delphi 10.4 Sydney, or a trick on how to install the Delphi 10.3 Rio package in Delphi 10.4 Sydney?

When I press F6 and then enter "Bookmarks" (without quotes), the Bookmarks item from View -> Tool Windows -> Bookmarks is NOT shown:

This is the whole list I get with F6:

Is this a bug?

Would any IDE plugin author be able to implement an OPTION to automatically focus the Form-Designer TAB when the user selects a control/component on the form in the Form-Designer?

This would be very useful until in an unknown future the above bug is maybe getting fixed.

As an alternative, a plugin author could simply implement a simple command to focus the Search Box of the Object Inspector.

22 hours ago, Uwe Raabe said:

You should describe your expectations with (very) detailed steps in QP.

A colleague has filed a Quality report here:

https://quality.embarcadero.com/browse/RSP-29906

Please everybody vote for this QP to have this nasty bug finally fixed! Thank you!

2 hours ago, Uwe Raabe said:

the Form Designer doesn't receive the focus after selecting another component

HERE lies the BUG: When selecting any element in the Form Designer (visual or non-visual component), the Form-Designer SHOULD automatically get the focus! This is the STANDARD BEHAVIOR in any other tool window of the IDE, where selecting a child element in the tool window causes the parent tool window to get the focus!

A Quality Report will be filed later today, where I kindly ask everybody to vote for it, to get this nasty BUG finally fixed.

23 minutes ago, Uwe Raabe said:

So there must be some difference between our systems

It SEEMS. Or try this one:

After some more testing in Delphi 10.4, the following behavior has emerged:

Right after showing the Form Designer with F12, I select a visual component in the Form Designer with the mouse and then I press F11. Result: The Object Inspector is shown and the focus is inside the search box.

Then I again select a visual component in the Form Designer with the mouse to make the Object Inspector lose the focus. Then I press F11 again which does not focus the Object Inspector but instead this time shows the Code Editor!

This suggests that the Object Inspector keeps some sort of "hidden focus". This makes the Object Inspector "believe" it still has the focus, which when pressing F11 the second time, instead of focusing the Object Inspector shows the Code Editor!

All IDE plugins are temporarily disabled.

1 hour ago, Uwe Raabe said:

when the focus is in inside the Form Designer and I press F11 the Object Inspector is shown and the focus is inside the search box. The Form Designer stays visible.

This is NOT the behavior I see here. As I said, when I press F11 in Form Designer the Object Inspector is NOT being focused. Instead, the Code-Editor is shown.

As I look at the Keyboard Shortcuts GExpert (sees screenshot above), the F11 key has only the Object Inspector function.