Where is Xojo 2026r2?

[Tim_Parnell]

Modals are not supposed to be so broken you can’t use them, no.

The design Beatrix mentions is standard and what I was taught. I’m pretty sure it was the suggested way to get a return value from a modal window.

[Beatrix_Willius]

@Thomas_Roemert

Isn’t window.showmodal forbidden since some years as it would crash the app?

Nope. Only ShowModalWithin has been deprecated and API2 uses ShowModal instead.

[Sascha_S]

@Beatrix_Willius

have a modal window with an init method to return a value. In the init method the window does a showmodal. The buttons in the window close the window. This now crashes in 2026r2.

Did you add a small example project to your report? I’d like to test it out. Where can I find the report, please?

[Thom_McGrath]

@Tim_Parnell

I’m shocked to see people calling this a monumental release worth renewing for.

Oh. I haven’t actually touched 2026r2, so the issues you speak of are all news to me.

@Beatrix_Willius

have a modal window with an init method to return a value. In the init method the window does a showmodal. The buttons in the window close the window. This now crashes in 2026r2. A “window.hide” instead of “window.close” seems to fix the crash. But I use that pattern like 10 times or so in the larger app.

This sounds very similar to a pattern I use often, but with some odd differences. If you’re closing the window to end the modal session, how do you read the values needed for the return value? And since a window is a class, you can utilize a constructor, so why does it have an init method?

The pattern I use most often is a shared method similar to:

Shared Function Present(Parent As DesktopWindow, InputValue As Integer) As Integer
  If (Parent Is Nil) = False Then
    Parent = Parent.TrueWindow // Because Parent may be a container
  End If
  
  Var Win As New ValueDialog(InputValue)
  Win.ShowModal(Parent)
  
  Var NewValue As Integer = Win.mValue
  Win.Close
  
  Return NewValue
End Function

So the action button hides the window, not closes it, otherwise I wouldn’t be able to read what I need from the instance.

But the init method is kind of vexing. The only time I’ve needed an init method is with a module since there’s no constructor. The constructor is the init method that you can’t forget to call. I’ve spent the last 8 months rescuing a project that used lots of init methods, and that was done because it uses introspection as a serialization system that will create instances to restore data into, so no constructors… and let’s just say there’s a reason the project needed rescuing.

[Tim_Parnell]

I built a demo project because I use the modal-return-value pattern as well, but I haven’t seen a crash. There must be a detail I misunderstood. I am glad to see the design hasn’t been broken.

Demo project: custom-input-modal.xojo_xml_project

[Beatrix_Willius]

The crash in the modal-return-value pattern was in the last beta but it’s not in the release. Here is an example:
modal return.xojo_xml_project.zip (7.9 KB)

The crash on quit is weird and only showed with 2 windows open: (made with Codex)

The crash is in Xojo 2026r2 debug teardown when an open SetupWindow is destroyed during app quit; SetupWindow.myClose finishes, but the actual window close/destructor path crashes. The fix avoids closing SetupWindow during quit, performs the main app cleanup from MainWindow , and then terminates the app directly, with extra logs around the quit path.

Something has changed in regard to closing windows and it doesn’t give me a warm and fuzzy feeling.

[Tim_Parnell]

@Beatrix_Willius

Something has changed in regard to closing windows and it doesn’t give me a warm and fuzzy feeling.

Something changed in class destructors that prevent my libssh2 classes from closing correctly. The destructor calls a declare to the library to clean up, but something Xojo did has made handles go missing. I don’t really care to figure it out since it’s very clearly a Xojo version related change for this project.

I wonder if it’s related at all.