Window.Close causing System.Beep to sound

Targets macOS
1

I have a strange occurrence in my application I’m opening a window that contains DesktopComboBox. If that combo box has focus when the OK button is pressed closing the window with WinRef.Close causes the system to beep. Has anyone seen anything like this.

My application has no System.Beep calls within it and there is no code attached to the Combo box.

Tracing the code through the debugger. The sound is happening when the WinRef.Close method is called. If the combo box does not have focus when the window is hidden there is no beep.

Window1 has the following code in a button:

Var oWindow As winFont = New winFont
' Load Setttings
oWindow.ShowModal( Self )
If oWindow.OK Then
  ' Save Settings
End If
oWindow.Close ' <------- this is the line that goes beep

On the combo box there is no code.

On the OK button there is the following:

OK = True
Hide
2

Can you reproduce it in a small new demo project? If so can you upload it.

3

I tried creating a cutdown version and it didn’t show the problem. Which is very odd.

Even more strange if I change the ok button code to:

popFontName.SetFocus ' <------ another control on the window.
OK = True
Hide

The problem goes away. I tried adding a new Combobox and that showed the same problem. Again with no code attached.

4

Could you post screenshots of the inspector of the winFont and Window1 window?

5

This is winPreferences (window1)

winPreferences
winPreferences602×1418 100 KB

This is winFont:

winFont
winFont638×1414 108 KB

and this is the combo box inspector:

winFont-Combo
winFont-Combo608×1370 88.4 KB

6

And how do you open winPreferences ? What is the code like for that, on a button or a menu?

What xojo and os version?

7

Via a menu handler on the App class:

Var oWindow As New winPreferences
oWindow.ShowModal
Return True
8

winPreferences doesn’t need to close to cause the beep. Only the winFont.

9

What xojo and os version are you using?

10

The latest 2021r3.1

11

I was putting together an example for a bug report and it failed to reproduce the issue.

12

big sur, catalina, high sierra, monterey?

13

Monterey 12.2, M1 Max MacBook Pro 16"

14

Can you try using Window.Hide instead of Window.Close?

15

winFont uses Hide in the OK and Cancel buttons. Once the details are read by winPreferences it calls Window.Close to tidy up afterwards. The beep doesn’t happen until you dispose of the winFont instance. It only happens when the combo box has focus when the window is hidden. Changing focus before hiding prevents the beep from happening. It feels like something in the core of combobox is generating a beep for some reason.

This is winPreferences, the Grid button opens winFont

winPreferences
winPreferences1466×800 83.1 KB

This is winFont:

winFont
winFont1466×822 83.2 KB

The contents of the combobox:

winFont-Combo
winFont-Combo1466×822 82.6 KB

16

OK, I’ve reproduced it, the project is attached to this bug report:
<https://xojo.com/issue/67528>

You have to open a window via the menu item for it to happen. If you simply call it from a window it doesn’t happen.

1 Like
17

A few weird things about your project:

  • you have Window.ImplicitInstance true for some of the windows, which isn’t a good idea (but not relevant here)
  • you have Window.MenubarVisible False for some of the windows, which isn’t a good idea (not sure if it’s relevant here)
  • usually, when writing dialog window code, you have the window close itself, e.g.:
Button1.Cancel
  OK = false
  self.Close

You have Self.Hide instead and then are calling .Close from the other window. Not sure why you are doing it this way…

When I replace Self.Hide with Self.close, and remove the other call to oWindow.close, the behavior is normal and there is no beep.

18

The outer window needs to read the settings from the dialog window. The winFont is called from four different places. The window needs to exist after closing so that it can be read from by the caller. Thus the reason it only hides things. The dialog builds an object and the caller reads the object and applies it to the correct parent setting.

In my example it sets the font for a data grid, graph titles, graph labels and graph legend. Putting all that code into the dialog isn’t a good idea in my view.

If you do Self.Close then the window structure is destroyed and you can’t read the result from the dialog.

Will take a look at the menus and implicit instance settings, they are not on purpose.

OK is also a property of the dialog. Self.close would destroy that value.

Just tried adding a menubar to each window. No difference.

Looked at ImpicitInstance and it seems to be on by default for DocumentWindows added to an API2 project. I didn’t set it that way, it seems Xojo did. Changing all window to false still results in a beep.

19

It would appear the .Close does leave the properties available but the controls are not. I agree that the calling function should not be accessing the controls but is is possible to write code that does.

Attempting to access the controls after .Close causes a NilObjectException. Using .Hide allows both methods to work.

20

You could do something this:

Write a method on the Modal dialog:

Function ShowModalAndReturnResults as MyResultsClass
    self.showModal
    if OK then
         dim x as new MyResultsClass
         x.fontName = ...
         x.fontSize = ..
         return x
    else
        retun nil ' user canceled
    end if

Then, from the parent window, you can just do this:

dim w as new MyDialogWindow
dim x as MyResultsClass = w.ShowModalAndReturnResults()

I find this is a cleaner design as it makes expclit what data is being returned…

1 Like