Uwe Raabe

I usually write class helper for this. They can easily be removed when older versions are dropped.

Perhaps someone can write a DFM-to-Balsamiq converter. It's pretty much just a SQLite database.

Not that I am aware off. A workaround could be to open and save all forms in D2007 on a system with PixelsPerInch = 96.

The handling of PixelsPerInch has changed in recent Delphi versions with High DPI support. This may be the cause of what you see here.

Resizing an array to a smaller length doesn't invalidate the other elements. You should have range checking on to catch this error.

Indeed, it is a method with MethodKind = mkOperatorOverload.

No problems here. Everything working as expected. I am not aware of having tuned something for that.

Indeed, currently Hyper-V doesn't play well with any other hypervisor system. This is going to change in the near future at least for VMware Workstation, though.

Taken from: http://docwiki.embarcadero.com/RADStudio/Rio/en/Per_Monitor_V2

I would like to discuss a feature here before creating a QP entry for that (which seems not to be possible in the moment anyway). There is often the case where I want some controls to be emphasized somehow by adjusting the font style or font color. This will automatically set ParentFont to False . As a drawback the control will no longer act on any changes to the parent font - obviously. In times of VCL styles and the ability for the user to change style and font, this can lead to a bit of extra work to get things looking pretty again. What would you think of a feature like: Yes, I want to use the ParentFont, but don't touch my font style and/or font color settings. I have something in mind like the StyleElements property, where you can select which font properties are to be inherited from the parent and which are not. What do you think?

I included everything available just to not miss something. I agree that the list can be reduced. After all, it is only a suggestion - not the implementation. It might be worth to add your comment to QP, so it will find its way to the person in charge.

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

I can confirm that even for 15.0.12 - a fix is in the pipeline. As a workaround add these files to the Excluded list: System IdGlobal IdThreadSafe

Of course there are workarounds and you can always do such settings in the code. I know there are suggestions to get rid of the DFM in general and do all in the code. On the other hand there are plenty of people that prefer setting such things in the Object Inspector.

Getting rid of something can be a bit tricky when you need to maintain your code also with older versions. The basic idea is to introduce that new property with an empty default value matching the current behavior. This will keep the DFM clean and ParentFont functioning as before. These are the parts for a possible implementation: type TFontElement = (pfeCharset, pfeColor, pfeHeight, pfeName, pfeOrientation, pfePitch, pfeSize, pfeStyle, pfeQuality); TFontElements = set of TFontElement; The new property ParentFontElements would be initialized with an empty set, which would be omitted when writing the DFM. property ParentFontElements: TParentFontElements read FParentFontElements write SetParentFontElements default []; The implementation would not affect any rendering at all. It can be implemented completely inside TControl.CMParentFontChanged without any impact to any other place. procedure TControl.CMParentFontChanged(var Message: TCMParentFontChanged); begin if FParentFont then begin if Message.WParam <> 0 then SetFont(Message.Font) else SetFont(FParent.FFont); FParentFont := True; end else if FParent <> nil then begin { TODO : order might be relevant } if pfeCharset in ParentFontElements then Font.Charset := FParent.Font.Charset; if pfeColor in ParentFontElements then Font.Color := FParent.Font.Color; if pfeHeight in ParentFontElements then Font.Height := FParent.Font.Height; if pfeName in ParentFontElements then Font.Name := FParent.Font.Name; if pfeOrientation in ParentFontElements then Font.Orientation := FParent.Font.Orientation; if pfePitch in ParentFontElements then Font.Pitch := FParent.Font.Pitch; if pfeSize in ParentFontElements then Font.Size := FParent.Font.Size; if pfeStyle in ParentFontElements then Font.Style := FParent.Font.Style; if pfeQuality in ParentFontElements then Font.Quality := FParent.Font.Quality; end; end; The ParentFontElements are only used when ParentFont is False, which is automatically set when changing some Font properties. Thus setting ParentFontElements must internally set ParentFont to False and trigger CM_PARENTFONTCHANGED: procedure TControl.SetParentFontElements(const Value: TParentFontElements); begin if FParentFontElements <> Value then begin FParentFontElements := Value; FParentFont := False; if (FParent <> nil) and not (csReading in ComponentState) then Perform(CM_PARENTFONTCHANGED, 0, 0); end; end; Apart from some real world testing and adjusting this is probably all that is needed for an implementation.

F.i. SnagIt uses Shift-F9 for Video Capture per default.

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

For new units you can enforce that with this registry setting (example for Delphi 10.3):

Me too, but just because I still have to maintain a couple of projects with older Delphi versions. While it is possible to handle that with conditional defines, that means double work for inline variables.

According to the 80/20 rule, whereas 80% of the work can be finished in 20% of the time, you actually have spent 15% of the time needed to get 100% of the work done

I have to confess that regarding the PPL I am the same idiot as you. On the other hand, it is like with all tools: You have to know how to use them and especially know where you have to be careful. As much as I love OTL I am often not in the position to make the decision for it.

Not precisely, but the Set active platform button in the Projects Window hits it pretty close:

AFAIK, TFDTable does something like that when used in Live Data Window Mode, but the implementation seems to be pretty complicated.

After a very, very long beta phase I finally released MMX Code Explorer V15. Thanks to all beta testers for their help and patience. A really big thank you goes to all who donated for the new MMX icons.

Seems I messed up Caption and Title somewhere. Will be fixed in the next release.