Uwe Raabe

Make sure that the DLL can be found.

The CreateXX are class functions. Therefore they don't change LocalMatrix itself, but return a new matrix instead. I'm not sure if I understand you right, but it might be sufficient to set the RotationAngle of the StrokeCube according to the vector V between those two spheres. The Y value should get the angle (in degrees) in the X/Z plane, while the Z value should get the inclination angle to that plane (not tested).

When working with styles, the Color property of the form is ignored. Unless seClient is removed from its StyleElements property, the forms client space is controlled by the style.

A TCustomPanel is not filled with a color, but with part of the style bitmap (defined in the GroupBox.Frame object). In a lot of cases this may be similar to a solid color, but it can as well be some texture or even a transparent area for some styles like Amakrits. You might really get the best results with setting the labels Transparent property to True.

What type of control is the Parent of the label (TForm, TPanel,...)?

See here: Update: You can see what colors are returned here: function TUxThemeStyle.DoGetStyleColor(Color: TStyleColor): TColor; begin case Color of scBorder: Result := clWindowFrame; scButtonDisabled: Result := clBtnFace; scButtonFocused: Result := clBtnFace; scButtonHot: Result := clBtnFace; scButtonNormal: Result := clBtnFace; scButtonPressed: Result := clBtnFace; scCategoryButtons: Result := clBtnFace; scCategoryButtonsGradientBase: Result := $C0C0C0; scCategoryButtonsGradientEnd: Result := $F0F0F0; scCategoryPanelGroup: Result := clMedGray; scComboBox: Result := clWindow; scComboBoxDisabled: Result := clWindow; scEdit: Result := clWindow; scEditDisabled: Result := clWindow; scGrid: Result := clWindow; scGenericBackground: Result := clBtnFace; scGenericGradientEnd: Result := $C0C0C0; scGenericGradientBase: Result := $F0F0F0; scHintGradientBase: Result := clInfoBk; scHintGradientEnd: Result := clInfoBk; scListBox: Result := clWindow; scListBoxDisabled: Result := clWindow; scListView: Result := clWindow; scPanel: Result := clBtnFace; scPanelDisabled: Result := clBtnFace; scSplitter: Result := clWhite; scToolBarGradientBase: Result := $C0C0C0; scToolBarGradientEnd: Result := $F0F0F0; scTreeView: Result := clWindow; scWindow: Result := clBtnFace; else Result := clNone; end; end;

That depends on the definition of correct.

As I never use any dark theme myself I am thankfully not affected. Nevertheless, I would rather question the decision to make clBtnFace and clWindow looking quite similar in the dark theme, while they give a perfect contrast in the light theme.

I did some deeper investigation not concentrating on the colors itself and it turned out that HideSelection was True under some conditions. I fixed that in the latest beta. Can you please try and see if this helps a bit?

That would require to configure this color for all possible themes. The IDE comes with three, but works with any valid VCL style. The better approach would be to select a VCL style that matches your preference. This would even work without fiddling around with the MMX sources Another approach would be to file a feature request to change the standard themes color to something more visible. The problem with that is, that it is hard to show with a vanilla IDE installation.

Short answer: It doesn't use any color. The colors are intrinsic to a the selected IDE theme and not part of MMX. The difference you see in the selected colors are caused by comparing different controls. MMX uses a derived TListView for the members and TTreeView for the content, while the IDE uses a special VirtualTree version. Each have separate colors inside a theme. I'm not aware that TTreeView or TListView are used elsewhere in the IDE, which may explain why nobody complained about these colors up to now.

Looks here as expected:

There is no problem to have separate units for each form and still have them work together for whatever they are supposed to do. It is just difficult to give general advice instead of answering questions about a concrete problem. Things that come to mind: Use a data unit (TDataModule or a plain unit) to group the file access at one place. Restrict the forms to the UI stuff and call the data unit classes or methods as appropriate. Ideally, each for unit only uses the data unit. I'm pretty sure there are ways to accomplish that.

No, you should use separate units for each form and keep the {$R *.dfm} directive in each. The * makes it match with the unit name and the IDE will keep unit and form file names in synch. Please refrain from packing multiple forms into one unit. Otherwise you will most likely flood this forum with questions about the problems you get, while the correct answer will always be: Don't do that!

You can have multiple forms open in the IDE, each in its own unit. If you want multiple designers for each form, you need to create separate edit windows with New Edit Window. The usual way is to have a separate unit (pas and dfm) for each form. There are rare cases where declaring one or more form descendants in the same unit without the ability to design can make sense.

You can contact Devid Espenschied

The Architect SKU is in fact an Enterprise SKU with additional licenses for some external tools (RAD Server Multi-Site, Sencha Ext JS Professional Edition, Aqua Data Studio). This SKU can only be detected from the license, so an IDE plugin can query the SKU and will return Architect with an appropriate license.

I cannot check this in my environment as I neither have a Personal Edition nor a Community Edition at hand. I can just share that my Architect Edition shows Enterprise in the details, which is expected because Enterprise and Architect differ only in the licenses for some external tools. Given the previous findings, the Product name seems to be a valid approach to detect the installed edition.

In terms of SKU, the Community Edition is in fact a Professional Edition. It is just the License restrictions that make it a CE.

The IDE as well as MSBuild are using the dproj file of your project, while the compiler only sees the dpr. At the end of the dproj file there is an import command for CodeGear.Delphi.Targets, which itself imports CodeGear.Common.Targets. The latter sets the UnitAliases given to the compiler.

If a unit is resolved by the -A option, any double occurrence is silently resolved, too. So, strictly speaking, the error is not suppressed in the sense of it is an error, but we don't show it, but rather internally resolved by removing the superfluous occurrences. In my blog article Conditional Uses Clause Considered Harmful one of the suggestions (Solutions 2) actually makes use of this behavior.

The IDE implicitly adds an alias for Generics.Collections=System.Generics.Collections which suppresses that error. Although not specified in the project itself, this alias is added in CodeGear.Common.targets.

As you are already accessing TabSheet6.Controls, you better use ControlCount instead of ComponentCount.

It also scales the image if the requested size is not present.

Let me guess: fRepCompEnrolment is a form containing a component named sctRepCustListt (not sure about the trailing doubled t, but I copied it) of type TSctReport? Then the file where fRepCompEnrolment is declared is the pas file you are looking for. It can still be that that .pas cannot be found and it works because the compiled .dcu is used instead, but that would be pretty uncommon for this case.