PeterPanettone

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.

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.

The Enter/Return key in the Form Designer only focuses the Object Inspector without setting the cursor inside the Object Inspector's Search field! (As the F11 key in the Code Editor does). And pressing the F11 key one more time has already set me into the Code Editor - where I don't want to be, as I have pressed the F11 key in the Form Designer!

The same bug still appears in Keyboard Shortcuts GExpert in r3195 for Delphi 10.4:

In Delphi 10.4, TCategoryButtons.TButtonCategory.TButtonItem does not have a Tag property. So I cannot write: CategoryButtons1.Categories[0].Items[0].Tag := 1; Is there a trick to add a Tag property to TButtonItem without rewriting the whole class?

Sometimes I wish we had a Tag1 and Tag2 property.

Thanks! TButtonItem.Action.Tag is the most simple and therefore the best solution.

In the Delphi 10.4 Code Editor place the caret on an identifier and right-click to open the context menu and select the Search for Usages... menu item: This opens the Search for Usages dialog: When you click the Search button, the list of usages of the searched element is presented: Now, supposedly double-clicking on any of the found items in the list would jump to that element in the source code? Unfortunately, this is NOT the case. Double-clicking on any of the list items does SELECT that element in the source-code - but it does not jump to its position. So this feature is completely useless! Why did Embarcadero implement a feature which is not usable and therefore is completely useless?

This is a work in progress. So I ask the moderators to keep this first posting in the topic editable so it can be updated as information is coming in. There is a number of modern VCL PANEL controls with special features acting on their content. AFAIK there is no existing comprehensive and structured overview of such panels, so I am planning to create one. Among such panels: Native Controls: • TCardPanel • TStackPanel • TFlowPanel • TGridPanel • TRelativePanel • TTitleBarPanel Third-Party Controls • TRzGridPanel • TRzFlowPanel Please feel free to add items to this list according to the above definition: VCL Panel controls with special features acting on their content.

In a Delphi 10.4 VCL Application, I have a TPageControl container with a TTabSheet page (with TabVisible = False) and a TPanel on that TabSheet: Although the Panel has Align = alClient, the Panel does not completely fill the TabSheet area: The TabSheet creates a MARGIN AREA around the Panel which I cannot get rid of. (The margin area is from the TabSheet and not from the Form, as the Form.Color is set to Fuchsia). So I thought I could make the margin invisible by setting the TabSheet color to the same color as the Panel. BUT TTabSheet does not have a color property! I have attached the very simple project, so you can play around with it yourself: TabSheetColor.zip Question: Is there a way to set the color of the full area of the TabSheet or to remove that margin from the TabSheet?

Good idea. Could you provide some example code?

If you have several panels then the handling becomes expensive. Anything about the TPageControl/TTabsheet?

Voted for it. Currently, there are 10 votes. Which number of votes would convince the product management to act?

I strongly agree.

Could someone who has a good knowledge of building plugins just add an automatic action to the DoubleClick action on the Search for Usages list item? The required action would be very simple: Scroll the caret position into view.

I have now tried Search for Usages in 10.3.3 --> No frozen IDE, same behavior as in Delphi 10.4: Double-clicking a search result item does NOT jump to that item in the source code.

BTW: IMO, a better and clearer naming consistency after : "DelphiXx10Seattle", "DelphiXx101Berlin" would be: "DelphiXx102Tokyo", "DelphiXx103Rio", "DelphiXx104Sydney" When dealing with humans, REDUNDANCY is a must.

Thanks!

Just for curiosity: What was the cause?

GreatisUltimatePack is an old LEGACY Delphi library with still useful components and routines. AFAIK GreatisUltimatePack has been discontinued and the author cannot be reached anymore. For anyone who still wants to use this library: To make GreatisUltimatePack compatible with Delphi 10.4 Sydney you should apply these changes: Search the units for: {$IFDEF VER330} {$DEFINE XE2PLUS} {$ENDIF} Then add these lines to the above lines: {$IFDEF VER340} {$DEFINE XE2PLUS} {$ENDIF} This should make it possible to install the component package in Delphi 10.4 Sydney: Ultimate.dpk

The possibilities in Delphi are endless. The compiler is your friend!

Renamed these files. Now I have: C:\Program Files (x86)\Common Files\ParnassusShared\ParnassusNavigator_XSydney.dll C:\Program Files (x86)\Common Files\ParnassusShared\ParnassusCoreEditor_XSydney.dll C:\Program Files (x86)\Common Files\ParnassusShared\ParnassusBookmarks_XSydney.dll C:\Program Files (x86)\Common Files\ParnassusShared\ParnassusCoreEditor_XRio.dll C:\Program Files (x86)\Common Files\ParnassusShared\ParnassusNavigator__XRio.dll C:\Program Files (x86)\Common Files\ParnassusShared\ParnassusBookmarks_XRio.dll And it still works. Very flexible DLL search algorithm!

Thank you very much! This solved the problem.

Thank you very much! This solved the problem. Now I have these files: C:\Program Files (x86)\Common Files\ParnassusShared\ParnassusNavigator_XSydney.dll C:\Program Files (x86)\Common Files\ParnassusShared\ParnassusCoreEditor_XSydney.dll C:\Program Files (x86)\Common Files\ParnassusShared\ParnassusBookmarks_XSydney.dll C:\Program Files (x86)\Common Files\ParnassusShared\ParnassusCoreEditor.dll C:\Program Files (x86)\Common Files\ParnassusShared\ParnassusNavigator.dll C:\Program Files (x86)\Common Files\ParnassusShared\ParnassusBookmarks.dll What did the developer THINK when he changed the overall search location for his DLLs in Parnassus 10.4? Did he think at all? What DLL search location can we expect in the next version of the Parnassus plugins?

Microsoft File Explorer is such an outdated legacy tool. When you use Directory Opus as a replacement for Microsoft File Explorer you get an automatic preview of ALL text files (including all Delphi file types of course) with syntax highlighting and these features: The Directory Opus preview uses the preview handler from Rodrigo Ruz and has everything you could wish for in your wildest dreams: