PeterPanettone

The most ANNOYING brake shoe in Delphi programming is the stone-age linkage of the structure panel content to the current type of editor: • In the CODE EDITOR the structure panel always shows the identifiers of the code edited in the editor. • In the FORM DESIGNER the structure panel always shows the list of object instances of the current form in a tree view. PLUS, there is a linkage between the OBJECT INSPECTOR content and the selected object in the structure panel (but only if you are in the FORM DESIGNER; the INSTANCES LIST on top of the Object Inspector is unusable because it is not displayed as a tree view and its width cannot be resized). But what if you are in the code editor and need a specific object to be displayed in the Object Inspector? There are two possibilities: 1. You switch to the Form Designer by pressing the F12 key, support the flickering of the tool windows, then select the desired object to display it in the Object Inspector. 2. Or: You click the Instances List Combobox on top of the Object Inspector and spend a lot of time finding the desired object (because it is not displayed as a tree view and the width is not resizable). All this is an unnecessary loss of time because of the mentioned stone-age linkage. So, would it be possible with a piece of software to solve these problems? For example: • Show the Structure Panel with its object instances treeview even if you are in the code editor? • Have an Object Inspector Instances List in the form of a treeview and with resizable width? Also, there is no distinction between visual and non-visual elements in the structure panel displaying the objects tree: There is no button in the Structure Panel to show only the visual objects or only the non-visual elements. Could any of these problems be solved by a GExpert?

Delphi is wonderful for small projects. But if you have a middle-size or large project, the mentioned drawbacks (e.g. the linkage of the structure panel content to the current type of editor) are annoying and time-consuming.

Actually I work with Delphi 3. I am glad you helped me to understand.

And which style exactly did you add? I am still waiting for the screenshots.

Where exactly did you add "STYLE"?

Could you please show me a screenshot of that "bluish color but so faint that it is almost not there".

Very impressive!

I do not think you are a novice.

Can you please show a screenshot while you hover the mouse pointer over a menu-item (and move the mouse a little bit), does that menu-item get highlighted? Thank you!

Thanks for the information. When you hover the mouse pointer over a menu-item (and move the mouse a little bit), does that menu-item get highlighted? Can you please show a screenshot?

What do you want it to do? Making coffee?

The MMX Find next/previous occurrence feature is VERY USEFUL! However, it should be possible to ENLARGE THE WIDTH of the dialog with the mouse: In this screenshot, you can see that you have to manually augment the Source column to see the searched identifier in the displayed source code line. Of course, the enlarged width should automatically be remembered between sessions. It would also be useful if the searched identifier would be somehow (e.g. with different font color) marked inside the displayed source code line.

Here is a SO question about this matter, where one answer says to use ZeroMemory and the other answer says to use Default: https://stackoverflow.com/questions/5509394/how-can-i-quickly-clear-a-record-of-simple-types What is the PRO and CONTRA of the two alternatives?

Thanks. Can you please show a short code example in the context of the above project?

OK, I have optimized it, and now it works perfectly as I want it: A nice STICKY POPUP MENU! Here is the source code: StickyPopupMenuSimulation_3.zip

Remy, with your hints, it is now partially working: procedure TPopupListEx.WndProc(var Message: TMessage); var mii: MENUITEMINFO; begin inherited; if (Message.Msg = WM_ENTERMENULOOP) and (Message.WParam = 1) then begin // customize pmTest items as needed... ZeroMemory(@mii, sizeof(mii)); mii.cbSize := sizeof(mii); mii.fMask := MIIM_STATE; mii.fState := MFS_HILITE; Winapi.Windows.SetMenuItemInfoW(Form1.pmTest.Handle, 1, True, mii); end; end; Now, when I show the popup menu the first time, the menu item with index 1 is highlighted: But then, when I hover the mouse over the first menu item, BOTH menu-items are highlighted: Instead, the second menu-item should become un-highlighted when the first menu-item becomes highlighted. Why this is not the case? Only when I hover the mouse over the second menu-item and then back to the first menu item, the second menu-item becomes un-highlighted: So I repost here the changed source-code, so everybody can see how the code looks in detail: StickyPopupMenuSimulation_2.zip

I want to either expand the functionality of the Get Component Names GExpert to somehow include the CLASSNAME of the selected component(s) or to create a similar GExpert which gets the CLASSNAME instead of the component name. (The former solution could include an additional keyboard-shortcut configuration for the classname, inside the same GExpert). So I looked at the GxOtaGetComponentName function: function GxOtaGetComponentName(const AComponent: IOTAComponent): WideString; var Component: TComponent; begin Assert(Assigned(AComponent)); Result := GxOtaGetComponentPropertyAsString(AComponent, NamePropertyName); if IsEmpty(Result) then begin Component := GxOtaGetNativeComponent(AComponent); if Assigned(Component) then Result := Component.Name; end; end; The parameter NamePropertyName is defined as a constant with the value 'Name'. Since there is no constant NamePropertyClassName, I assume that the class name of a component can be in any case simply retrieved by Component.ClassName and has not necessarily be retrieved by GxOtaGetComponentPropertyAsString. So I would naively propose this function to get the class name: function GxOtaGetComponentClassName(const AComponent: IOTAComponent): WideString; var Component: TComponent; begin Result := ''; Assert(Assigned(AComponent)); Component := GxOtaGetNativeComponent(AComponent); if Assigned(Component) then Result := Component.ClassName; end; What do you think?

Now I have tried it out by replacing the old function GxOtaGetComponentName with the new function GxOtaGetComponentClassName in the unit GX_CopyComponentNames: CurrentComponent := FormEditor.GetSelComponent(i); //ComponentName := GxOtaGetComponentName(CurrentComponent); ComponentName := GxOtaGetComponentClassName(CurrentComponent); It works perfectly. Now it's time to decide how the new functionality Get Component ClassNames should be implemented: 1. Combine the component name and class name in one string, e.g.: ComponentName (ComponentClassname) 2. Provide a second keyboard-shortcut box for the class name inside the existing GExpert, e.g. F5 for the component name and CTRL+F5 for the component class name 3. Create a separate GExpert for the component's class name. Plus: Provide a small configuration dialog where one of the above choices could be configured. Please select your favorite choice.

Now I have done it: Got me a Mac (MacBook Pro 16", 64 GB RAM, 4 TB SSD, 8 GB Graphics) with Parallels Desktop Pro and Windows Home 10 (not the crippled N-version for EU-ropeans). Installed the latest Delphi RIO 10.3.3 and got ... VERY small IDE UI fonts: In the above screenshot, I combined the IDE with the Windows 10 system settings window where you can see that my text size is set to 150%. The screen resolution is set to the monitor-native 3840 x 1600: on this monitor: LG UltraWide (3840 x 1600 pixel) (87 x 36 cm). So the final question: Is there a way to increase the IDE UI font sizes under these conditions?

I have a question about the list of Identifiers in the Uses Clause Manager: A specific identifier named SaveStringToFile is not found in the list of Identifiers although its unit (the unit name is MiTeC_Routines - it's a licensed unit ) is in the Library Path. Could it be because it's enclosed inside these compiler directives in the interface section of the unit? {$IFDEF RAD6PLUS} procedure SaveBytesToStream(ABytes: TBytes; AStream: TStream); procedure SaveBytesToFile(ABytes: TBytes; AFilename: string); procedure SaveStringToFile(AString: string; AFilename: string); overload; procedure SaveStringToFile(AString: ansistring; AFilename: string); overload; {$ENDIF} That's because of other identifiers OUTSIDE these compiler directives from the same unit ARE being found.

I have tried to clear the parser cache, but the identifier SaveStringToFile could still not be found.

Today I downloaded gexperts-code-r3054-trunk , extracted it to C:\COMP\_Addons\GExperts\GExperts Sourcecode\gexperts-code-r3054-trunk and tried to build it by loading: C:\COMP\_Addons\GExperts\GExperts Sourcecode\gexperts-code-r3054-trunk\Projects\DelphiXx103\GExpertsRS103.dproj into the Delphi 10.3.3 IDE. First, it complained about a file not found OUTSIDE (!) its own directory: [Exec Error] EXEC(1): File "C:\COMP\_Addons\GExperts\GExperts_Version.ini" does not exist. (ENoVersionInfo) So I copied it from C:\COMP\_Addons\GExperts\GExperts Sourcecode\gexperts-code-r3054-trunk\Projects\GExperts_version.ini to the required location. Then it complained about another missing file: [dcc32 Error] E1026 File not found: 'GExpertsRS103_version.res' So I RENAMED (!) C:\COMP\_Addons\GExperts\GExperts Sourcecode\gexperts-code-r3054-trunk\Projects\DelphiXx103\GExpertsRS103.res to GExpertsRS103_version.res. Only after these two actions, the GExpertsRS103.dll could be successfully built and is now happily living in the 10.3.3 IDE: Are these bugs inside the GExperts source code?

You're alright with David making you upset? Don't let your feelings get manipulated. Think rationally. The weather is beautiful today.

Thank you for the suggestion.

Is that a MORAL or RELIGIOUS assessment?