DesktopListBox and overloaded classes

Hi

This code worked before the new DesktopListbox was introduced.
Using a class that extends the MenuItem class like:
ClNewMenuItem as MenuItem

dim myNewMenuItem as ClNewMenyItem = New ClNewMenuItem( menuParameters… )

then it worked adding a contextual menu item in the ConstructcontextualMenu event by

Base.append( myNewMenuItem )

Changing the parent object from MenuItem to the new DesktopmenItem makes the Base.append( myNewMenuItem ) to be not possible any more

Does anyone have any suggestions?

I use this to detect if the user aborts a contextual menu by clicking outside the menu by catching the destructor of the ClNewMenuItem class .

/Hakan N

With DesktopListbox you have to subclass a DesktopMenuItem:
https://docs.xojo.com/DesktopUIControl.ConstructContextualMenu

If the user selects a menuitem then this event is fired:
https://docs.xojo.com/DesktopUIControl.ContextualMenuItemSelected

If the user cancels no event is fired.
So you don’t have to check if the user aborts or not.

hi Stefan
I’ve worked on an analyze application for some time now and I’ve a ListBox containing all user loaded log files. The normal selected files in the list includes the file in the analyze that the user performs. All menu items in the contextual menu of this list box shall valid for all files at any time. One problem that i’ve run into in the past was when the user chose the contextual menu on a file item that was unchecked and then abort, I’ve got bad behavior. The solution of this was to catch the abortion of the contextual menu. This has worked for me for a long time. As the situation is now I have realized that xojo have solved, but not told us, the speed issue when adding many items to a list box if you use the Desktoplistbox control. Therefore I now try to switch to the DesktopListbox instead of the old ListBox control and this is a hard task due to all name space changes that have been done. I want to minimize the work in doing this and therefore not change any thing else.
One peculiar thing that I noted is that Xojo have solved the speed issue but not using it in the xojo IDE. Debugging an array with many items overloads the IDE and you need to take it down by force and restart with the consequence of loosing the latest work.
/Hakan

Even if you create your own contextual menu …
I always check the result for Nil and then I know if the user aborted or not.


Var base As New DesktopMenuItem, result As DesktopMenuItem

base.AddMenu New DesktopMenuItem("Test 1", 1)
base.AddMenu New DesktopMenuItem("Test 2", 2)

result = base.PopUp
If result = Nil Then Return

// The user selected a menuitem

Select Case result.Tag
  
Case ...
  
End Select

Always save before run :wink:.

Use an IDE script to automatically save:

DoCommand "SaveFile"

3 Likes

Hi
Yes I’ve learned to save before debug, but sometimes you forget and by accident click on the too long array in the debugger. You blame your bad memory every time. In the meantime I will try the script Beatrix suggested.Thanks Beatrix.

It should be appreciated if the xojo IDE starts using the new desktoplistbox and fill it with the AddRows method from the array in the debugger. This will prevent the need for restarting xojo and make it possible to debug large arrays. My meaurement shows that DesktopListBox.Addrows is ~100 times faster than the old Listbox.AddAllRows method. Filling the list boxes with 10^5 items takes 0.0166154 s with the Desktoplistbox and 1.739523 s with the listbox control. In my application it’s common that the user have 10^7 items. With the DesktopListbox it’s manageable but not with the ListBox.

Stefan:
Thanks for your suggestion. Even if it becomes a strange solution adding code like:
Me.MyMenuResult = me.MyMenuItem.PopUp

if Me.MyMenuResult <> nil then
return me.mContextualMenuItemSelected( Me.MyMenuResult , self )
else
//abort code
end if

At the end of the listbox ConstructContextualMenu event and move all the code in the ContextualMenuItemSelected event into the mContextualMenuItemSelected method. It works.
/Hakan