However, we can't assign an existing ordinal type to our enumerated type.
Hi!
Ord / Pred / Succ existed in N. Wirth's first Pascal design < 1970.
Winni
Yes. But your function does not do what I'm asking.
It is not useless if I have a use for it.yea we all have such needs !
Wow... this place is such a waste of time...
on big machines Sir, yes! on micro-computers, tp introduced this around the year i said
In Pascal it is done shorter and more elegant:
Code: Pascal [Select]
procedure TForm1.SpeedButton1Click(Sender: TObject);
type
CalDays= (Sunday,Monday,Tuesday,Wednesday,Thursday,Friday,Saturday);
var
myDay : CalDays;
s: string;
begin
myDay := Thursday;
WriteStr(s, myDay);
Showmessage(s);
end;
@winni
Unfortunately, the declaration
type CalDays= (Sunday,Monday,Tuesday,Wednesday,Thursday,Friday,Saturday);
equates to
type TCalDays= (Sunday=1, Monday=2, Tuesday=3, Wednesday=4, Thursday=5, Friday=6, Saturday=7);
While it is still 1 step more required than what I would prefer, the GetEnumName() and GetEnumValue() functions are 1 step less than would be required using the WriteStr() function (they eliminate the need for use of a variable), and I think I can use them to work with current enumerated type structure as follows.
Hero Member
*****
Posts: 3950
Re: Getting a string representation of an enum value
« Reply #4 on: August 25, 2016, 04:20:17 pm »
Quote from: fatmonk on August 25, 2016, 04:19:36 pm
I did look at WriteStr() but missed that the result gets sent to the first argument...
I also edited my post to include the GetEnumName-example which is what WriteStr() uses internally.
I also edited my post to include the GetEnumName-example which is what WriteStr() uses internally.
rvkQuoteHero Member
*****
Posts: 3950
Re: Getting a string representation of an enum value
« Reply #4 on: August 25, 2016, 04:20:17 pm »
Quote from: fatmonk on August 25, 2016, 04:19:36 pm
I did look at WriteStr() but missed that the result gets sent to the first argument...
I also edited my post to include the GetEnumName-example which is what WriteStr() uses internally.
The line:QuoteI also edited my post to include the GetEnumName-example which is what WriteStr() uses internally.
from that post in the link I provided earlier is the only reason I went with the GetEnumName() function over the WriteStr() procedure.
I wish there was a way to verify whether that particular statement is true.
Type ControlCharacters = ( CTL_AKNWLDGMNT : Char = #6, //Control character; acknowledgment. CTL_BACKSPACE : Char = #8, //Control character; backspace. CTL_BELL : Char = #7, //Control character; bell ("ding") sound. CTL_CANCEL : Char = #24; //Control character; cancel. CTL_CRGRTRN : Char = #13, //Control character; carriage return. CTL_DATALINK : Char = #16 //Control character; data link. ); Type DrawingCharacters = ( DWG_ALT179 : String = '│', //Drawing character; line - single vertical. Equal to {Alt+179}. DWG_ALT180 : String = '┤', //Drawing character; right coupler - single vertical/single horizontal. Equal to {Alt+180}. DWG_ALT181 : String = '╡', //Drawing character; right coupler - single vertical/double horizontal. Equal to {Alt+181}. DWG_ALT182 : String = '╢', //Drawing character; right coupler - double vertical/double horizontal. Equal to {Alt+182}. DWG_ALT183 : String = '╖', //Drawing character; right upper connector - double vertical/single horizontal. Equal to {Alt+183}. DWG_ALT184 : String = '╕' //Drawing character; right upper connector - single vertical/double horizontal. Equal to {Alt+184}. );
Both Type enumerations above are non-functional mockups do demonstrate my needs.
For string enumerations, the techniques proposed so far will often work, though not always, especially if the string is long. It wouldn't make sense to have an enumeration element name that is 50 characters long.
Also, in such cases as above, it is not feasible to use the shown literal values and hash values as element names, either. In most case, it is the element value I need to access and not the element name. In cases where the required value would always be a number, this would not be an issue. However, the required value often needs to be a string or a character, which enumerated types do not allow.
I need...
ShowMessage(DrawingCharacters.DWG_ALT182); //Displays "╢"
rather than...
ShowMessage(DrawingCharacters.DWG_ALT182); //Displays "DWG_ALT182"
Why not use something like this?