Bug or Quirk

Hi all,
Hobbiest programmer. Just wondering if this is a bug or a quirk or just something I don’t understand.

On my Mac apps I create my own buttons by placing a label inside a small rectangle shape. The shape is the same colour as the background.

Then with the mouseEnter event, I can change the shape’s colour and/or bold the label etc. The mouseExit event will then return them both to default. Maybe not elegant, but it works and looks ok. I then use the MouseDown event on the label to execute the action.

One of the ones I usually create is an “X” from SFSymbols and use this to close a window that has been opened. I accidentally put the Window.Close action onto the MouseDown event for the shape recently and it crashed the app. I’ve tested this with another “test” app and the exact same thing happens. That is open a second window from the main one, place a square shape and try and close the window from the MouseDown event.

So, is this a bug or is something happening that I don’t understand?

Hope this all made sense.

You guys are awesome, as always, thanks for any help/insight.

What I do not understand is why you need to add a Close button. Isn’t the MacOS default Close button enought ?

What says the Debugger ?

BTW: Window.Close would close what ?
Xojo do not let you give Window as a window name. So, that is your error.

Ok, so the windows I usually create are floating windows with the 3 upper left buttons disabled and made not resizable. They are then opened in modal mode (not sure if that’s the correct terminology). Therefore I have to create a seperate button to close the window. Also, I don’t call the window “Window” I was just calling it that for the purpose of the question.

I appreciate your reply, but it still has missed the point of the question. Why does closing a window from the MouseDown event on a rectangle control crash the app, when it works ok from the Label control?

As far as the debugger, I actually get one of those internal MacOS messages telling me that Test.debug quit unexpectedly (note “Test” is the whatever the name of the app is) with 2 buttons to send a report or ignore. If I ignore I’m then left with XOJO still running as normal, but app shut down.

Personally I use MouseUp for the actual work of the button, as it affords the user, having pressed the mouse in the button, the chance to slide the mouse off trhe button and then release the mouse, without the action being done.

This requires a bit of extra logic, however.


Stated like that, it must not do that. But, the story is incomplete. What other differences are there between them ?
Is the code in DesktopLabel1.MouseDown:

Try Self.Close.

Exactly the same:


This is really just an education type question. I don’t normally do it from the rectangle, I do it from the label. It was just accidental that I discovered it so was curious. I’ll continue calling it from the label.

What version of Xojo are-you using ?

The use of a Rectangle that way (imho) is useless. Try a ContainerControl or… use the winow Events (Paint, MouseDown) to do the job.

That say, you may write a bug report if you care and believe it’s a bug.

There is no other involved code ? (in Rectangle, in the CancelClose / Close Events ?)

I would never use a label to create a button (excepted, maybe, in a MultiMedia software). I would use a Canvas with a nice icon… but this is me.

A DesktopContainer with just a canvas in it, in fact. Then you can paint on the canvas.

Yes, I can confirm what you say: putting
return true

in the mousedown event a rectangle, and clicking the rectangle, the app crashes;
while if the same code is inside the mousedown event of a label inside the rectangle the app does no crash.
Using 2021v2.1 on BigSur

Crash report:
Process: My Application.debug [5596]
Path: /var/folders/*/My Application.debug.app/Contents/MacOS/My Application.debug
Identifier: org.mysoft.myapp
Version: ??? (
Code Type: X86-64 (Native)
Parent Process: ??? [1]
Responsible: My Application.debug [5596]
User ID: 501

Date/Time: 2023-05-22 15:25:11.846 +0600
OS Version: macOS 11.7.7 (20G1345)
Report Version: 12
Anonymous UUID: CBBC6377-EC9A-D4DB-8CB6-67EF05F2920E

Sleep/Wake UUID: C4A87E7B-701D-48D2-AA91-E79A3BB47F04

Time Awake Since Boot: 65000 seconds
Time Since Wake: 820 seconds

System Integrity Protection: enabled

Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Exception Codes: EXC_I386_GPFLT

Termination Signal: Segmentation fault: 11
Termination Reason: Namespace SIGNAL, Code 0xb
Terminating Process: exc handler [5596]

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 XojoFramework 0x000000010fbbfc5e GetSubPaneWindow(SubPane*) + 20
1 XojoFramework 0x000000010fba8453 SubPane::Close() + 125
2 XojoFramework 0x000000010fba850d SubPane::Unlock() + 93
3 XojoFramework 0x000000010fae2753 EditRect::HandleClick(MouseEvent const&) + 119
4 XojoFramework 0x000000010f9f3923 0x10f8fe000 + 1005859
5 XojoFramework 0x000000010f9eed95 0x10f8fe000 + 986517
6 com.apple.AppKit 0x00007fff2324c76e -[NSWindow(NSEventRouting) _handleMouseDownEvent:isDelayedEvent:] + 4961
7 com.apple.AppKit 0x00007fff231bbf88 -[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] + 2594
8 com.apple.AppKit 0x00007fff231bb346 -[NSWindow(NSEventRouting) sendEvent:] + 347
9 XojoFramework 0x000000010f9efec3 0x10f8fe000 + 990915
10 com.apple.AppKit 0x00007fff231b9754 -[NSApplication(NSEvent) sendEvent:] + 352
11 XojoFramework 0x000000010f9e0464 0x10f8fe000 + 926820
12 My Application.debug 0x000000010f73a635 Application._CallFunctionWithExceptionHandling%%op + 181
13 XojoFramework 0x000000010fb631b4 CallFunctionWithExceptionHandling(void (*)()) + 254
14 XojoFramework 0x000000010f9e03e2 0x10f8fe000 + 926690
15 com.apple.AppKit 0x00007fff234924f1 -[NSApplication _handleEvent:] + 65
16 com.apple.AppKit 0x00007fff230225ee -[NSApplication run] + 623
17 XojoFramework 0x000000010fb61afe RuntimeRun + 41
18 My Application.debug 0x000000010f7b2763 REALbasic._RuntimeRun + 19
19 My Application.debug 0x000000010f809b5e _Main + 846 (/#main:103)
20 My Application.debug 0x000000010f808f93 main + 19
21 libdyld.dylib 0x00007fff2074cf3d start + 1

Thread 1:
0 libsystem_pthread.dylib 0x00007fff2072d420 start_wqthread + 0

Thread 2:
0 libsystem_pthread.dylib 0x00007fff2072d420 start_wqthread + 0

Thread 3:
0 libsystem_pthread.dylib 0x00007fff2072d420 start_wqthread + 0

Is this a case of unfortunate things happening when you overlap controls like that? Is this even supported?

If it makes it easier, this is the full example of what I do.

On any window, I create an array of small rectangles called recButton() and a corresponding array of labels called lblButton(). Each respective label is placed on the rectangle.

In the MouseEnter event of the rectangles:
me.fillColor = color.LightGray
lblButton(x).Bold = True

In the MouseExit event of the rectangles:
me.fillColor = RGB(… (whatever the background is)
lblButton(x).Bold = False

I then create method called ProcessButtons(index As integer)
This method is:
Select Case index
case 0
case 1

Each case then processes the code for the action of that button. One of them will be WindowXXX.Close

In the MouseDown event of the labels I call ProcessButtons(index) where index is the array number.

This works fine. As I said, maybe not elegant from a pro’s point of view, but it works. I’m always happy to try and learn tho. As for canvas, I think I tried that once a while ago and couldn’t get the hang of it so started using this method.

I don’t think it’s an overlapping control thing coz you can just have the rectangle sitting all by itself with no label on it and it will crash from if the close is called from it’s mouse down event.

Whilst it hasn’t answered the initial question, thanks for the other suggestions. I’ll have a look at canvas but, as you can see from the more extensive code I put up, this works because the rectangle has a simple 1 liner to change its colour with Fill. With the canvas I have to write much longer code to paint it don’t I? Or is there another way?

I would say, based on the type of crash, that this is the Xojo framework trying to access a recently freed pointer. That is, events are probably being scheduled before the window closes and then fire for something that no longer exists.

1 Like

whatever the workarounds, the fact is that a rectangle, even without any other object inside, crashes the app when calling self.close from the mousedown.event.
While it does not happen with labels or other objects.

Then the next thing is to make a small project (as small a project as possible) to demonstrate the matter and file an Issue.

Thank you for looking at the crash report which I do not understand.

In this case a rectangle. Why it does not happen with a label or whatever other object?
(retoric question).

Xojo would need to be able to look at the code paths and see what is different. Heck, it’s possible that it has to do with the fact that it’s a rectangle vs a control as technically a rectangle isn’t a control, but a decoration and the underlying OS hierarchy is different.

That’s why, as it was suggested, Barry should make a bug report if he thinks it wise to do.