Thanks. It compiles and works now.
In the latest Delphi VirtualTreeView version the typecast is changed to Byte or Word depending on the element count in a set.
I decided to do the same thing. Then I realized the code doesn't work with FPC 2.2.4, so I added {$packset 1} or {$packset 2} directives. {$packset 1} if elementcount < 9.
{$packset 2} if 8 < elementcount < 17.
And I changed the typecasts accordingly to Byte or Word.

For example:

  // Options per column.
  TVTColumnOption = (
    coAllowClick,
    coDraggable,
    coEnabled,
    coParentBidiMode,
    coParentColor,
    coResizable,
    coShowDropMark,
    coVisible,
    coAutoSpring,
    coFixed,
    coSmartResize,
    coAllowFocus,
    coDisableAnimatedResize,
    coWrapCaption,
    coUseCaptionAlignment
  );
  {$packset 2}
  TVTColumnOptions = set of TVTColumnOption;
  {$packset default}

Fine. Then I thought, what if someone will add more element into the set? 2 more element makes already 17 here.
I tested this "overflow of set space" situation with this:

  {$packset 1}
  TVTColumnOptions = set of TVTColumnOption;
  {$packset default}

The compiler should give an error but it doesn't! The code will not work as intended (I guess).

What happens if (without $packset directives) a set has 17 elements? Does it use 3 or 4 bytes? What if there are > 32 elements?

The casting here is used for streaming data, with Stream WriteBuffer and ReadBuffer.
Is there any better way of doing this than casting to Byte, Word or LongWord and counting the elements?

Juha Manninen

FYI
I am testing VirtualTreeView with its "Advanced" demo program. When I use FPC 2.5.1 and compile it with -O1, it works always however much I click the different forms.
When compile it with -O2 and click and test furiously it finally throws SIGSEGV. The message box says:

Project Advanced raised exception class 'External: SIGSEGV'.

Often it paralyzed my KDE desktop partly so that mouse commands didn't work. Then I selected terminal using keyboard and killed gdb and then things worked again. Sometimes it didn't freeze.

I tested the same VirtualTreeView code (with my added $packset directives) also with FPC 2.2.4 and it worked with or without optimization.

I understand the compiler is a devel version but if you need a good test case, here you have one.
I compiled whole Lazarus with FPC 2.5.1 and -O2 and it works well. VirtualTreeView has non-portable assembly code and may be difficult for the compiler.

Juha Manninen

Juha Manninen wrote

I understand the compiler is a devel version but if you need a good test case, here you have one.

Unfortunately, not really. A good test case is a small self-contained test program with no external dependencies that crashes or prints a wrong result. A lazarus package does not really fit this description.

I compiled whole Lazarus with FPC 2.5.1 and -O2 and it works well. VirtualTreeView has non-portable assembly code and may be difficult for the compiler.

The compiler does not optimize handwritten assembler code. The most likely problem is that this assembler code does not preserve all non- volatile registers, and that 2.5.1 uses one of those registers while 2.2.4 didn't. It could of course also be a compiler bug, but that is unlikely (for the simple reason that the main difference between 2.2.4 and 2.5.1 as far as optimizations are concerned, is that the compiler makes slightly better use of registers and that the i386 assembler CSE optimizer has been /disabled/ by default).

Jonas

Damn, I have fpc-pascal and fpc-devel messages in the same KMail folder and it somehow mixed the lists and jumped to another list. I will separate them to different folders.

Juha

Jonas Maebe wrote

You can just add {$packset 1} once. It simply tells the compiler that the minimal size by which it can increment the size of sets is 1 byte (rather than the default 4 bytes). It does not mean that the compiler will try to store all sets in 1 byte.

Thanks. Got it.
I placed {$packset 1} just after {$mode delphi} and it still works.

I will remember that. It would help also the Delphi version of VirtualTreeView, not just the Lazarus version.

Regards,
Juha Manninen