I have a question about Xojo capabilities; basically, are they able to read and interpret Apple Crash Dumps?
I found today that with a new install of my App, I can reliably cause a crash when the app is terminated, and that there is a “user-workaround” or I can comment out two statements upon either of which the crash doesn’t occur. Of course, if I do the latter, the app doesn’t really work properly.
Essentially, the relevant bit is that at startup, the app populates two menus. Various user actions may require the menus to be remade. I do this by recursively removing menu items until the menus are empty and then remaking them. If this is the first thing the user does, the app then crashes (segmentation fault) when quit. If the user does something with the menu first, even just like opening it, why - then no crash.
Sad to say, making a tiny test app which replicates the create/remove/remake menus steps described, exhibits no crash behaviour. So, is there any point in submitting a feedback, as the first thing they are going to ask for is is such an app.
OTOH, are they capable of looking at the crash dump and saying well xyz was happening at the crash moment, so were you doing any xyz? Then perhaps I can look elsewhere for the problem and make some progress.
curious, what if instead of removing specific menu items, what would happen if you always cleared out the menu completely and create from scratch? do you get same results on File Quit?
Yes
They keep all the required symbol files from building everything and should be able to use those to put symbols back into a dump and see what is crashing
I did also file a recent bug report about using close in enable menu items feedback://showreport?report_id=59284
Its absolutely reproducible
And the fix I’m not really happy with but
Not sure I follow here. This is what I do to clear out a menu (each menu item has an icon either as a file or a directory):
Public Sub removeMenus(menuPtr as MenuItem)
Var i, numItems As Integer, ptr As MenuItem
numItems = menuPtr.Count () - 1
for i=0 to numItems
ptr = menuPtr.MenuAt (0)
if (ptr.icon=directory) then removeMenus (ptr)
menuPtr.RemoveMenuAt (0)
next
End Sub
The menu is then empty and I recreate it using the same method that created it in the first place.
If you only have a tiny little bug then it’s not very likely that your bug is going to be fixed. Especially, when the Xojo people have to look at your whole app. They might do that in extreme circumstances.
The first one is really an obscure problem. The encoding of a string was missing. But the second one is a really bad one. What is happening with the 2 reports? Absolutely nothing.
ha! In my new job I was doing research on a bug and came across Feedback Report 5827 I submitted in 2009! Having this one event would solve a BUNCH of issues in the products for our company. There was a subsequent issue (11665) that’s gotten more traction. This one seems like such an easy win for Xojo…
But yes, Feedback certainly seems to be where good ideas and serious bugs go to die.
My thought process is to try to step through the menu before it gets manipulated. Example, do you get the same behavior if you populate the menu without removing anything. If that works, what happens if you redim the menu and populate from scratch, does that produce same behavior.
another example that I a curious about, looks like you are assigning the menuitem count prior to looping through, what I am not sure about is if you remove one menuitem and then proceed to iterate through the loop, doesnt the menuitem count change but the numItems is not updated from the original assignment? example, lets say you have 20 menuitems and you assign 20 to numItems. Now, as you are looping through the twenty the code finds that menuitem 5 needs to be remove. Once this is done, doesnt the index of menuPtr change? so with menuitem 5 gone does menuitem 6 become 5, menuitem 7 become 6, etc…
below is what I am referring to where the menu item index changes and when you remove one the index of remaining menu items changes.
// Add some items
base.AddMenu( New MenuItem("Test 1"))
base.AddMenu( New MenuItem("Test 2"))
base.AddMenu( New MenuItem("Test 3"))
// Add a Separator
base.AddMenu( New MenuItem(MenuItem.TextSeparator))
// Add a sub menu
Var submenu As New MenuItem("SubMenu")
submenu.AddMenu( New MenuItem("SubMenu Test 1"))
submenu.AddMenu( New MenuItem("SubMenu Test 2"))
submenu.AddMenu( New MenuItem("SubMenu Test 3"))
base.AddMenu(submenu)
// Add a Separator
base.AddMenu(New MenuItem(MenuItem.TextSeparator))
MessageBox base.MenuAt(1).Value
base.RemoveMenuAt(1)
MessageBox base.MenuAt(1).Value
Return True
I’ve just written a custom container control that has a separate control for the headers that lets me do whatever I want with the headers
I have a couple glitches to fix but so far it works as a drop in replacement for a listbox - sort indicators, icons, font, colors, different size etc
How do you handle coloring the background X-platform so it looks at home with native list boxes?
That is something that made me hesitant to write my own.
If I were to do my own I would consider making it be multi-row because I often use headers and sub headers (2 line headers) in tables:
| Main Category |
|--------------+---------------|
| Sub Cat1 | Sub Cat2 |
|--------------+---------------|
| Data | Data |
Not all headers need to be two rows. The ones with no sub headers would just have their entry centered vertically.
BTW the approach I thought of was using the paint events to always paint the the top row(s) as the header and override all the methods that take a row/Cell index to adjust them for the offset. For multi-Row headers is where my mergeable listbox code would come in handy so I could still use the standard listbox borders.
as norm stated, its like an array. In your current code, I see you do this first
then you start your loop
the problem I see with this is, once you remove an item, the index of the menu items change; however, your loop doesn’t account for the change of index. What I am curious is if the issue is referencing an index item that used to exist an index x and then try to reference it, its possible you might be facing a OutOfBoundsException error.
Rich, you’re not reading my code. I’m not referencing an item at index x, I’m referencing the zeroth item, and removing the zeroth item. If I have 20 items and I keep removing item zero, then when the loop finishes the menu will be exactly empty. If I were removing the i’th item then you’d have a point. But I’m not.
The crash is a hard crash reported to me by macOS, not an error reported to me by Xojo in the form of an OOBE error.
There are some things I would try. In no particular order:
From your initial post I gather that the crash happens, if the user calls a menu by shortcut instead of “opening” it with the mouse, right? If that’s true, call the global EnableMenuItems methods right before the user has the first chance to call the menu. So maybe at the very end of the App.Open event, or, if you have a main window, at the end of that window’s Open event. This may have the same effect as the user clicking the menu with the mouse.
How do you initially populate the menu? Do you initially set it up in the menu editor in the IDE or via code? If it’s in the menu editor, try to do it completely in code.
Inside the for loop test if ptr is nil.
I’m not sure about the if (ptr.icon=directory) then ... part. Try if (ptr.count > 0) then ... instead. In my experience accessing the Icon property of a menu item can be a bit fragile, if it is nil. But then again I’m still using Xojo 2017, so that problem may have been solved.
And maybe you don’t even need to remove the menu items recursively. What happens if you just remove the parent item? Does the crash still happen? Are the sub-menus properly closed, or are they kept in memory?