Lars Fosdal

My guess: The SetPosition / Seek ends up with an out of bounds address?

5 hours ago, Ondrej Kelle said:

Not really when writing my own code, I try to avoid them if possible.

Sometimes for interop with an API, e.g. when translating C headers where enums are already declared that way.

Or when you need to support a binary format which uses some specific ordinal values, then it depends - you might still prefer to use an enum but avoid conversion.

I still prefer using regular constants for bit-fiddling.

Interesting. Has anyone done any benchmarking of the MSOLEDBSQL driver vs the SQLNCLI driver?

Interesting. Does Rapid function properly with RTTI as well?

Just curious: Has anyone seen a valid use case for defined ordinal values in enumerations?

Just now, Leif Uneus said:

Define "weird". Enumerations with defined ordinal values do not have RTTI.

That is the "weird" right there.  Definitively a good reason to avoid defined ordinal values in enumerations. 

19 hours ago, Stefan Glienke said:

When used in a set, the ordinal value of the enum is basically the index of the bit used within the set and as they can only be 256 bit in size any ordinal value above 255 prevents an enum being used as a set.

Personally I think you should rather avoid giving enums any ordinal values and only ever use them when using some interop with another system where they are used for.

Isn't there something weird about RTTI for enums that have manually set ordinal values as well?

I did mean dynamic arrays. My bad. 

Off-topic: There is another oddity with enumerations with explicit ordinal values.

TEnum = (plough = 5, foo = 9, bar = 14, wtf = 1000);
The above is valid, but wtf can't be used in a set.

Makes me wonder if it would be better to generally do sets as dynamic arrays, instead of today's implementation of sets.
I guess it would be more expensive.

Right you are, @dummzeuch : Problem solved.

To where are you trying to save the file?

Now I am suddenly not so happy about the Parnassus integration in 10.3.  It murdered my 10.2 Parnassus plugins.

I think it could be fantastic if it was possible to design custom property lists per class.  The first time a class is seen, it could be added to a list of class property configs, with all the props present.  In a config dialog somewhere, it could be possible to enable/disable each prop.  The filter could even use digits 0..9 to select one of multiple configurations per class. Naturally, if it could be installed with default filters for many of the standard components, that would be nice. I really like the idea - more than I like quick edit. Nice work!

Very odd.  I did have 10.3 from November installed and did a reinstall and the uninstall hung at the end.  Perhaps I need to redo it 😕 - or wait until the new laptop arrives.

I do love that Parnassus Bookmarks and Navigator is included, though!

Installed 10.3.1 using the web installer.  Something looks strange. 

No 10.3.1 mention.  Installed update is 10.2 update 2?

On 2/5/2019 at 7:01 AM, haentschman said:

Hi all...

The last version was imho XE. I've written to Uwe before... without an answer. Everyone who knows Uwe has no contact more...

@Uwe Schuster: We need only the SourceCode...please.

He lives at https://twitter.com/uscle?lang=en

How does SourceTree and Github Desktop compare?

2 minutes ago, Stefan Glienke said:

You should take a break - because it in fact is related to the ordinal value. The order is wtf, plough, foo, bar - but your array was wtf, plough, bar, foo

Declared:   TEnum = (plough, foo, bar, wtf)
Test order: [wtf, plough, bar, foo]

Looping an Enum Set
1 wtf
5 plough
9 foo
14 bar

Looping an Enum Array
1 wtf
5 plough
14 bar
9 foo

Press Enter:

You are right, @Stefan Glienke -I am so logging off now 😄

1 minute ago, Stefan Glienke said:

It does not, bar and foo are still reversed 😉

1

Wow, I didn't notice that!  And it is not related to declaration order, nor ordinal value. That is a bit disturbing.

The inconsistent behavior between the two variations of enumerated types is another pitfall, I guess.

Or pitfall 😛

Off-topic - I actually do reverse for in loops with a custom enumerator which starts on top and decrements instead.

@Uwe Raabe

Are you saying that

for ix := Low(Array) to High(Array)

do begin

  v := Array[ix];

is predictable - while

  for v in Array

is not predictable ?

I wonder how it behaves if I have a set enumerated type with hard coded ordinal values?

Edit

Change the declaration to   TEnum = (plough = 5, foo = 9, bar = 14, wtf = 1);

Now the set behaves just like the array.

7 minutes ago, Stefan Glienke said:

I could answer that by quoting your previous comment 😉

 

 

Except it is rare to see a TList or any other object structure "hardcoded" in plain sight, while arrays of simple types are not hard to read nor uncommon.