Mike Torrettinni

Great, thanks! I didn't think about this at all. I was thinking somebody will come up with some trick how to do complicated if else for this, but this is smarter solution.

I've been using Git for a few weeks only, so I could be way off base here... but doesn't every conflict have details on who changed what that conflict occurred in the specific file? Is it your username for all the changes?

"Use AnsiStrings instead of Strings. Unicode strings are inefficient." I noticed this as last comment in one of my old SO questions: https://stackoverflow.com/questions/35942270/charinset-is-much-slower-than-in-should-i-fix-w1050-warning-hint ( scroll to the bottom) Is this just one man's opinion, or is there any validity to it? Is it suggesting that when dealing with string manipulation functions, to convert Unicode string to Ansistring variable type, process the Ansistring and then convert back to Unicode for display/export...? My projects are all in Delphi 10.2, so they all work with string types - Unicode strings. And all works good for importing, processing, exporting and displaying data even for international customers. So, all works good. Should I look into if any string manipulation methods would be faster with working on Ansistrings? Or should I just ignore the comment and move on? Thanks!

He commented: "The CharInSet function suffers from the fact that the set must be stored in memory because it is specified as a function argument. Thus the compiler can't generate fast arithmetic instructions that operate on CPU registers. It has to use the much slower memory bit-test instruction. So there are multiple memory accesses per iteration (non-inlined: function call, bit-test, function return; inlined: 2x stack juggling, bit-test) compared to none" ""Sets are far less efficient": Not in this case. The compiler is smart enough to change the long element list to ['A'..'Z'] itself and then it uses the fast if (c >= 'A') and (c <= 'Z') to implement the in-operator. And that also with correct code for WideChar as long as the set elements are Ord(x)<=#127." This is quite impressive insight about compiler! I just googled him and I see he is the developer of DelphiSpeedUp and IDEFixPack and other tools! I feel quite honored he took the time to make those comments 🙂

Good idea!

I use a lot of input data manipulation, but none specific is really slow, and now I see there is no reason to even think about if String <-> Ansistring would make them any faster.

Great, good to know I don't need to worry about this! I remember in D2006 I had to use all sorts of 'magic' with input strings, UTF8Decode/Encode, WideString* conversion methods, switching system locale to test customer's language, locale settings... nice to know that stays in the past! 🙂

I would welcome opening sub forum, especially if Embarcadero will not offer official forums, anymore. If in a year you see is not making any traction, you close it. At least you tried, but if it offers good resource for developers and it is active, it would be shame to not offer it. Set a threshold how many positive response you get here, 5, 10, 20... and then decide. My vote is for a subforum.

I downloaded just demo exe at first and it didn't work, it needs full directory with all dlls to run. Demo works pretty impressive. Not sure where I could use these controls, but good to know. Probably source code doesn't have English comments.

Looks pretty good. I was able to run demo exe.

When I need to design UI that is rather unique (or I've never done before), I always try to get ideas form existing tools. I just search google for keywords that make sense and look through screenshots of tools, software, web apps... sometimes I combine ideas to fit my needs. I try to avoid 'wizard' style where each step is it's own tab, that means in step 2 I don't see info from step1 or step 3. i prefer more info vs less info. The immediate idea I got from your description was 2 VistualTreeViews (VTV), 1 on the left (25% width) as work-flow (steps) and main VTV (75%width ) with details. That way you can see at which step of the overall l process you are at this moment, while the details of current step are in the main VTV. And VTV is very customizable, icons, check boxes, combo boxes...

I have functions A, B and C, and I need to return True if any of the function calls returns True, while all functions have to executed. In this example - as I would usually setup function calls: IsAnyTrue returns True if A, B or C functions are True A,B,C functions have to executed function IsAnyTrue1: boolean; begin Result := false; if A then Result := True; if B then Result := True; if C then Result := True; end; I can shorten this with: function IsAnyTrue2: boolean; begin Result := false; Result := A or Result; Result := B or Result; Result := C or Result; end; OR! I just realized, I can do it like this: function IsAnyTrue3: boolean; begin Result := false; Result := A or B or C or Result; end; But! This will trigger 'boolean short-circuit' rule. In this case I would need to use {$B+} to force full boolean expression evaluation - all A, B and C functions to be executed always. Are there any other ways how I can setup Result and always execute all functions?

This seems to be the winner, so far. It doesn't need any extra setting up (Funcs arrays, temp variables, ...). I can add as many as I need, and I don't need to change any other expressions (Result := A or B ...). The simpler Result := Eval(...) or Result = A or B... looked really good in simple examples, but as soon as you have any comments needed or additional conditions, the winner becomes a better choice. Thank you, I really appreciate all suggestions!

I have this example of TProjectType and the consts of values and record helper. type TProjectType = (ptMain, prExternal); const cProjectTypeXMLNames: array[TProjectType] of string = ('xml_main', 'xml_external'); // Project type imported from XML cProjectTypeNames: array[TProjectType] of string = ('Main project', 'External project'); // Project name to show user type TProjectTypeHelper = record helper for TProjectType function ToString: string; function XMLName: string; end; function TProjectTypeHelper.ToString : string; begin Result := cProjectTypeNames[Self]; end; function TProjectTypeHelper.XMLName : string; begin Result := cProjectTypeXMLNames[Self]; end; function GetProjectTypeFromXMLName(const aName: string): TProjectType; var i: TProjectType; begin Result := TProjectType(0); // default for i := Low(TProjectType) to High(TProjectType) do if cProjectTypeXMLNames[i] = aName then Exit(i); end; If I add 10 more enums, I need to copy 10x all this code, and make changes as needed, but template stays the same. For TDocumentType I would just copy&paste all, set new enum and consts values and replace ProjectType -> DocumentType in helper and function. Is there a way to use generics, so I don't need to copy&paste this for other enums?

Your example gave me an idea, that I completely missed. I don't need 2 consts, 1 should be enough: const cProjectTypeNames: array[TProjectType] of TTypeAsName = ( {ptMain} (DisplayName: 'Main Project'; XMLName: 'xml_main'), {ptExternal} (DisplayName: 'External Project'; XMLName: 'xml_external') ); This is then easier to extend, adding additional name, and if there are many values, which you would split into multiple lines in code, the names are aligned and you can't make a mistake. The only drawback is, if you have 10 values, this becomes 10+2 lines, while before it was 4 lines for 2 consts, total.

That's good. So, when I have type and values 1:1, I can use Attributes and no need for helpers.

@David Heffernan Would you still use Attributes if you have 2 sets of string values (Names, XMLNames...) for a type? This doesn't compile: [Names('Curvature', 'Bend angle' )] [XMLNames('XMLCurvature', 'XMLBendAngle' )] TPreBendSpecifiedBy = ( pbsCurvature, pbsBendAngle );

I assume you have some code-gen tool for any changes to these enums, or adding new types? Excel? 🙂

Aha, I see you wrap everything into record helper, consts and FromString function. I didn't really know about it.

Yes, I do use that in some cases, but rarely when the value is shown to user - there will always be 1 value that is not 'presentable'. (no spaces between words, not all xml values comply with standards...)

Aha, but if each type requires different attribute values, each type has to have it's own attribute. That's how I understand your example and documentation, but have no actual experience with attributes, yet.

Yes, you are right. For a few minutes I was excited about the possibility 🙂

Yes, probably not really usable for my case of multiple values connected to enum. I wish this function would be somehow shortened or connected to type, like record helpers. Now it kind of stands on its own. function GetProjectTypeFromXMLName(const aName: string): TProjectType;

If I have 10 different types, would I still need to defined 10 different Attribute classes: type ProjectAttribute = class(TCustomAttribute) ... Using Attributes, could I avoid setting same code for 10 different types?

Oh, too bad. Thanks.