SAve dialogue of a vst after renoise clese

Help, Support & Bugs
1

I am a big fan of the wonderfull vst synth called tranzistow .
In the latest update there is a bug that is beyond the scope of the developer
WHenever a new patch is loaded a save dialogue pops up for confirmation , but when ignoring this dialogue and closing renoise ,the dialogue closes with renoise but is still active , and thus windows desktop becomes unresponsive …here’s a quote from the developer about the issue

quote

Yes, weird, I agree. I noticed this with Renoise only - “Save Yes/No” dialog was hanging after closing the DAW for the reasons which are out of my scope (because I cannot debug the DAW). I reworked them to use standard Windows MessageBox function in the latest version and now Renoise just closes/ignores them on exit. Still weird but at least they are not hanging anymore.

Are you saying that you have the same problem with the latest version (2024-04-03) too?

unquote

2

i’ll try on linux there is a windows wich appear to said if i want to record the preset i say yes and it seem to work

3

The point is , when you ignore the window ( don’t click it ) and then close renoise , windows desktop becomes unresponsive because that " trranzisoow save window ’ is still active somewhere , but where ???
There is nothing in taskmanager that suggest there is still a runnng process happening .

4

When i closed renoise i have a windows wich ask me if i want to save and i say yes and it works but i ll save it before a name for the preset to name it

5

LIke I said before "
-Do NOT click on the window " ,
-Do NOT click on yes ,
-Do NOT click on NO
Just ignore it , DO not interact with it ,
then close renoise .
The window is now still active ( somewhere )

6

Yes i know

7

But you could save after that renoise is closed

8

Renoise is hanging in the tranzistow message box’s message dispatcher.

From what I can see here, the modal dialog’s owner window is the wrong one: It should be the plugin window that Renoise creates to host the plugin UI or the Renoise main window, but it seems that the owner instead is the plugin content window from tranzistow.

If you have a contact to the developers, please tell them to contact me directly here or via taktik@ nameOfThisSoftware.com

11

This is the response of the developer after I provided him with the info you’ve given above
quote

If this is the case then those modal dialogs would hang in all cases, not just on close. So, this is not the cause.

Yes, it hangs in message loop but the sequence of events which lead to this is quite strange:

(1) For some reason Renoise reports an older version of ComCtl32 library being used:

Hrastow, Reaper: $6000A
Renoise: $50052

Due to this, custom FPC/Lazarus dialogs are used, not the Windows TaskDialogIndirect which is available in $60000 and up.

(2) Tranzistow receives WM_Quit message from somewhere. I haven’t figured out if this is from the host or from somewhere in FPC/Lazarus framework. IMHO, this shouldn’t happen because (according to Win32 API) WM_Quit “indicates a request to terminate an application” and DLL is not an application.

(3) And finally, for another unknown reason, this WM_Quit message ended up being posted back into the same queue by dialog message processing loop, again and again, causing an endless loop.

I solved it in the latest versions by simply doing a dummy WM_Quit processing to get it out of the queue on close. This is only for Renoise because I found a way to detect if Tranzistow runs under Renoise by querying the class name of a plugin window.

Note: All the above applies to Diodow as well.

unquote