Hierarchical pop-up Combo Gadget

[zapman*]

The code above has been updated.
The eventtypes generated by the new gadget are now exactly the same as for a classical ComboBox, so you can replace one by the other wthout changing anything in the rest of your codes.

[TomS]

Nice. Here is the create-Procedure that works like PB-Gadgets:

Example 1:

Code: Select all

combomenu= CreateComboBoxMenuGadget(#PB_Any, 170, 25, 140, 20)
AddGadgetItem(combomenu, -1,"Spaghetti") ;... and so on

Example 2:

Code: Select all

CreateComboBoxMenuGadget(1, 170, 25, 140, 20)
AddGadgetItem(1, -1,"Spaghetti") ;... and so on

This allows things like the use of enumerated constants, and looped gadget-creations.

Here the new procedure:

Code: Select all

Procedure CreateComboBoxMenuGadget(ID.i, iX.i, iY.i, iWidth.i, iHeight.i,Option=0)
	AddElement(hCBM())
	If ID = #PB_Any
		hCBM()\iGadgetID = ComboBoxGadget(#PB_Any, iX, iY, iWidth, iHeight,Option)
	Else
		ComboBoxGadget(ID, iX, iY, iWidth, iHeight,Option)
		hCBM()\iGadgetID = ID
	EndIf 
		hCBM()\iMenuOpen = 0
		hCBM()\iOldCBMCallBack=SetWindowLong_(GadgetID(hCBM()\iGadgetID), #GWL_WNDPROC, @CBMCallBack())
		ProcedureReturn hCBM()\iGadgetID
	EndProcedure

[Demivec]

Using the most recent code and compiling under Windows XP it displays a box after the last item in the menu. I'm guessing the box is due to the LF character that is added to the last menu item but is it supposed to display this way?

[TomS]

No it's not. There is no problem with that under Win7.

Find this line

Code: Select all

If Right(mline$,1)=Chr(10)

And strip down the mline$.

Code: Select all

Left(mline$, Len(mline$)-1)

That should fix the problem.

[Demivec]

And strip down the mline$.

Code: Select all

Left(mline$, Len(mline$)-1)

That should fix the problem.

I made the change so that it now reads:

Code: Select all

If Right(mline$,1)=Chr(10); the Chr(10) at right of text will close the submenu
  CloseSubMenu()
  mline$ = Left(mline$, Len(mline$)-1)
EndIf

and all is now well. Thanks.

[Demivec]

@TomS: I spoke too soon, I discovered another problem. As a reminder I'm using Windows XP.

After an item containing the close sub-menu code has been selected it shows the command character as part of the selected entry.

[TomS]

You're right.
That's because zapman* uses the ComboBox-Items.
I tried to find a workaround, but I think it's not possible, if you want to use AddGadgetItem()
What you can try is to use Chr(2) to Chr(31). I can't test it, because I have no problem with Chr(10) under Win7.
Maybe Chr(160) will do the job (protected Space).

[zapman*]

@Demivec:

It seems that the character #9 presents no problem: viewing your screen capture, I see no problem with the line "sauces".

So, I propose to use only this character: a simple chr(9) to open the submenu, a double chr(9) to close it. Please try this in the GUY declaration:

Code: Select all

AddGadgetItem(combomenu2, -1,"Spaghetti")
AddGadgetItem(combomenu2, -1,"Great sole")
AddGadgetItem(combomenu2, -1,"Potato omelette")
AddGadgetItem(combomenu2, -1,"Fondue chinoise")
AddGadgetItem(combomenu2, -1,"Tapioca soup")
AddGadgetItem(combomenu2, -1,"Duck liver")
AddGadgetItem(combomenu2, -1,"Sauces"+Chr(9)) ; add Chr(9) to right of the text will open a submenu
AddGadgetItem(combomenu2, -1,"Chili")
AddGadgetItem(combomenu2, -1,"American")
AddGadgetItem(combomenu2, -1,"Indian")
AddGadgetItem(combomenu2, -1,"Kebap"+Chr(9)+Chr(9)); add double Chr(9) to the right of text will close the submenu

and this at the begining of the CBMCallback procedure:

Code: Select all

            For ct = 0 To CountGadgetItems(hCBM()\iGadgetID)-1
              mline$ = GetGadgetItemText(hCBM()\iGadgetID,ct)
              While Right(mline$,2)=Chr(9)+Chr(9); a double Chr(9) to the right of text will close the submenu
                CloseSubMenu()
                mline$ = Left(mline$,Len(mline$)-2)
              Wend
              If Right(mline$,1)=Chr(9); a Chr(9) to right of the text will open a submenu
                  OpenSubMenu(mline$)
              Else
                MenuItem(ct+10000,mline$) ; we use menu items over 10000 to avoid conflicts with other application menus
              EndIf
            Next

@TomS

One more time, your suggestion is brilliant. I just modified a little bit your code to make it more logical:

Code: Select all

Procedure CreateComboBoxMenuGadget(ID.i, iX.i, iY.i, iWidth.i, iHeight.i,Option=0)
  ;
  ReturnValue = ComboBoxGadget(ID, iX, iY, iWidth, iHeight,Option)
  AddElement(hCBM())
  If ID = #PB_Any
    hCBM()\iGadgetID = ReturnValue
  Else
    hCBM()\iGadgetID = ID
  EndIf 
  hCBM()\iMenuOpen = 0
  hCBM()\iOldCBMCallBack=SetWindowLong_(GadgetID(hCBM()\iGadgetID), #GWL_WNDPROC, @CBMCallBack())
  ProcedureReturn ReturnValue
EndProcedure

The code above has been updated with those modifications.

[Demivec]

It seems that the character #9 presents no problem: viewing your screen capture, I see no problem with the line "sauces".

@zapman*: When an item is selected with the 'close_submenu' code it is displayed in the selection portion (at the top) with the extra characters displayed as boxes. It does not happen with the line "sauces" because you cannot select that line, it only displays the sub-menu instead.

Even though I am using Windows XP, I suspect it may be showing the characters also in other Windows OS's, the characters are just defined without a visible image. When the line "Kebap" is selected while debugging it also displays the extra characters in the debug window, which means that programs would have to take this into account when reading the selected values from the combo-box.

[zapman*]

I'm also using XP without any problem and I think that it does not depend on your system version but on some special configuration of your computer.

Ok, if not any other option is found, we could use a simple space and a double space, but I don't really like that.

Did you test chr(160) as suggested by TomS ?

[Demivec]

I'm also using XP without any problem and I think that it does not depend on your system version but on some special configuration of your computer.

Ok, if not any other option is found, we could use a simple space and a double space, but I don't really like that.

Did you test chr(160) as suggested by TomS ?

zapman*: chr(160) does work visually . There is a side-effect that should be noted with any line entries that containing the "close-submenu" cmd character. The character is a part of the entry and may cause difficulty if one is trying to match the selected entry against a list of the entries contents (instead of using the index). In retrospect that probably is not be a common thing way to use a combo-box and so I'll not worry about it.


Something else though, I notice that for the MenuItems you use ID#'s starting at 10000 and above. With most other kinds of ID#'s this would still cause space to be reserved for items below that number. Since a MenuItem can't use a #PB_Any kind of number system there doesn't seem to be a way around that. Do you foresee any problems with setting aside that many entries?


I have one additional bug to report. I wanted to see what would happen if more than one hierarchical-combo-box (whew, what a mouthful) was used at the same time. I created another one with about the same number of entries and assigned it's ID# to the variable 'combomenu3'. So I had one combo-box and 2 hierarchical-combo-box's. I'll refer to them as boxes 1, 2, and 3.

When I ran the test with the debugger. I selected box #2 to see it's drop-down menu list. Without selecting anything from box #2's menu's I selected box #3 to see it's drop-down list. This is when I got a nerror in this section of code:

Code: Select all

If PeekMessage_(@msg.MSG, hwnd, #WM_LBUTTONDOWN, #WM_LBUTTONDOWN, #PM_NOREMOVE) = 0
  ; menu has been closed!
  FreeMenu(hCBM()\iMenuID) ; <= error occurred here: The specified #Menu is not initialized.
EndIf

Instead of stopping there I ran the code from that point and there were no more further problems switching between box#2 and box#3, both displayed their menu's as they should.

[TomS]

Well , I guess it would be easier if zapman* implements his own AddComboMenuItem()-Procedure. This would help the problem with the opening and closing character and the high IDs.

I'll try to understand the hook, zapman* used to display the folder-icon in the menu and implement it in my version, I postet earlier.
So 'normal' PB-Code is not 1:1 interchangeable, but I don't think that should be the goal of a userlib/include.

[zapman*]

zapman*: chr(160) does work visually . There is a side-effect that should be noted with any line entries that containing the "close-submenu" cmd character. The character is a part of the entry and may cause difficulty if one is trying to match the selected entry against a list of the entries contents (instead of using the index). In retrospect that probably is not be a common thing way to use a combo-box and so I'll not worry about it.

Okay, okay, you're right. By luck, there is a field inside the ComboItem Structure wich can be used for special needs by the application. I've just discovered it. So I've updated my code (still at the begining of this topic) using that field instead of a character at the end of the item text.

I added to functions: OpenSubMenu_CBM and CloseSubMenu_CBM. That is far more elegant than the precedent way of doing the things.

Something else though, I notice that for the MenuItems you use ID#'s starting at 10000 and above. With most other kinds of ID#'s this would still cause space to be reserved for items below that number. Since a MenuItem can't use a #PB_Any kind of number system there doesn't seem to be a way around that. Do you foresee any problems with setting aside that many entries?

I really not foresee any problems with that.

I have one additional bug to report. I wanted to see what would happen if more than one hierarchical-combo-box (whew, what a mouthful) was used at the same time. I created another one with about the same number of entries and assigned it's ID# to the variable 'combomenu3'. So I had one combo-box and 2 hierarchical-combo-box's. I'll refer to them as boxes 1, 2, and 3.
When I ran the test with the debugger. I selected box #2 to see it's drop-down menu list. Without selecting anything from box #2's menu's I selected box #3 to see it's drop-down list. This is when I got a nerror in this section of code:

Code: Select all

If PeekMessage_(@msg.MSG, hwnd, #WM_LBUTTONDOWN, #WM_LBUTTONDOWN, #PM_NOREMOVE) = 0
  ; menu has been closed!
  FreeMenu(hCBM()\iMenuID) ; <= error occurred here: The specified #Menu is not initialized.
EndIf

Instead of stopping there I ran the code from that point and there were no more further problems switching between box#2 and box#3, both displayed their menu's as they should.

Thank you very much for this very good debugging and report work. The problem came from a very vicious situation due to the fact that the current list element was changed by one callback while the other one was still running. I think that the code is now fixed for that.

Thanks again for your help

[Michael Vogel]

Hi,
when you click on the close button of the main window, the #Gadget is not initialized error is still there...

[zapman*]

Sorry

It's fixed.