Leaderboard

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?

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.

I placed another copy of the DLLs under "Windows/SysWow64" and now it seems to find the DLLs. It would help debugging if calling "WhichFailedToLoad" or possibly the InnerException would return the GetLastError value from the LoadLibrary function.

I'm pretty sure, that is not what he meant. You will run into real problems once you tackle the last 20%, that is what the rule says. And as a rule, you may try to do the hard part first...but it will always be the last to be finished. Life just sucks that way.

You mean, you want a relation between Country name and app's locale? Why not use the system's locale? If your customer is Chinese living in Australia (I heard there are many) he probably wants Chinese labels not English. I'd let user decide what language he prefers.

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 just try to use UTF8 everywhere and get rid of all ANSIs completely

Without BOM every file-handling utility is usable even that which knows nothing about UTF8. I had some shaman dances with XE2 and resource compiler trying to make them handle UTF8 properly and they all disliked BOM. Now 10.1 seems able to handle BOM UTF8 which is good but old habits remain for a while.

IMHO BOM causes more troubles than profit. I just remove it from every file I have