The patch failed on SetComboHeight and the compilation failed on TLocalCustomComboBox.
I have applied the patch and fixed the compilation manually. Please check this.

Endless loop?
Is the win32 intf checking, if MultiSelect and Sort are already set? A RecreateWnd should not result in an endless loop. It is an allowed operation. Especially as the VCL uses it a lot.

Why not fix LM_CREATE in the win32 intf to create a Handle with the correct flags and add some code to LM_SETxxx to check if RecreateWnd is needed?

PS: not recreating the handles, makes the listboxes to be drawn (but works fine)incorrectly (Looks the same problem as TMemo), but it's not a new bug. It's a previous hidden bug. In the other side, allows the user to use the combobox at ObjectInspector :-)

:{
a phyrus victory

Mattias

There's a problem (AKA bug) in RecreateListControl: the windowproc address is not being set, which breaks link between listboxes and comboboxes and LCL.
I tried to rework the procedure setting the properties at same order of LM_CREATE, but i got unusable controls.
The patch comments RecreateListControl calls and rewrite the procedure to accomplish the above, although without sucess.
It also cleans SetComboHeight(Sending WM_SIZE message is no more necessary) and fix a
Note that MultiSelect, Sorted implementation rellies at recreating the handle.

I see four ways to go:

1) Find a way to change MultiSelect, Sorted properties under win32 on the fly, without recreating handle. The ideal, although improbable.

2) The properties could be set in LM_CREATE handling, so TWincontrol.RecreateWnd could be called. Now the cited properties are set after LM_CREATE, with LM_SETSORTED and LM_SETSELMODE which causes a endless loop calling RecreateWindow.
This has a good side effect: now the handle are created three times for each ListBox(LM_CREATE,LM_SETSORTED,LM_SETSELMODE) and twice for each combo. The problem is that should be defined at LCL that these features should be checked/set at create handling.
This is the most viable

3) Doesn't allow to change these properties at runtime under win32 ????

4) Fix the problem in RecreateListControl. Volunteers, please.

PS: not recreating the handles, makes the listboxes to be drawn (but works fine)incorrectly (Looks the same problem as TMemo), but it's not a new bug. It's a previous hidden bug. In the other side, allows the user to use the combobox at ObjectInspector :-)

karl

-------------- next part --------------
A non-text attachment was scrubbed...
Name: zip00032.zip
Type: application/octet-stream
Size: 2966 bytes
Desc: "new.zip"
Url : http://localhost/pipermail/lazarus/attachments/20030826/d334fa93/zip00032.obj

It can/should be:

LM_SETSORTED
-> call RecreateWnd
-> call CreateHandle
-> LM_CREATE
-> create sorted like Delphi
<-
-> LM_SETSORTED
<- already set

Probably we can remove the LM_SETSORTED call in the LCL on initialize wnd.

Mattias

Phyrrus was an ancient king (read: time of the Romans). After some famous battle against the Romans was won, his army was decimated: the cost of victory was extremely high. Phyrrus said something like

"that another similar victory would ruin him"

Hence: "A phyrric victory".

Michael.

Thanks.

Lazarus is culture :-)

karl

Well explained.

Actually, most of the times his name is written in English as Pyrrhus. (helps finding it with a search engine).

Vincent.

Mattias Gaertner wrote

On Tue, 26 Aug 2003 18:23:29 -0300 Karl Brandt wrote:

<snip>

We can check the current state of these properties and call recreate only if they are different(LCL and Win32).
But in most cases the check will be useless:
Just after creating the control the Recreate will never be called. Afer runtime change, will always be recreated because LCL already check if the value is different

I prefer setting the Sort/SelMode at create handling and removing UpdateSorted and UpdateSetSelMode from CreateHandle(TCustomListBox) and UpdateSorted from CreateWnd(TCustomComboBox)
This will avoid the cited redndant check.

The only drawback is that gtk intf must be updated (set the Sort/SelMode at create handling)

I'm sending a patch that works changing the LCL as said above. Tested. To work without changing LCL is necessary to do the second check, which i can do if you prefer.

It also fixes the order of the items in assign and size issues with TCustomListbox

karl

-------------- next part --------------
A non-text attachment was scrubbed...
Name: zip00035.zip
Type: application/octet-stream
Size: 2992 bytes
Desc: "recreatelist.zip"
Url : http://localhost/pipermail/lazarus/attachments/20030827/4c7b9acf/zip00035.obj

The problem is that UpdateSelection and updateSorted are called inside CreateHandle so this is the sequence:

LM_SETSORTED -> call RecreateWnd -> call CreateHandle - Send LM_SETSORTED -> call RecreateWnd -> call CreateHandle ...

This was my first try when i try to get selection yo work

But if is needed to recreate the above problems will happen

sorry but what's phyrus?

karl

Now the obvious question: what does Lazarus mean ;-)

Michael.

And for the rest we need the check.

Just after creating the control the Recreate will never be called. Afer runtime change, will always be recreated because LCL already check if the value is different

Custom controls ported from Delphi can send unneeded messages. It is good programming practice to check if ReCreate is needed.

I prefer setting the Sort/SelMode at create handling and removing UpdateSorted and UpdateSetSelMode from CreateHandle(TCustomListBox) and UpdateSorted from CreateWnd(TCustomComboBox) This will avoid the cited redndant check.

Exactly my opinion.

The only drawback is that gtk intf must be updated (set the Sort/SelMode at create handling)

Done.

Applied.

Mattias