Please allow OpenWindow inside threads

[PMV]

Error on GNU Linux + MacOS X, and on Windows: "Warning: Using OpenWindow()/WaitWindowEvent() within threads is incompatible to GNU Linux and MacOS X!"?

That is what this thread and the other threads are for ...

but

[...], so with DisableDebugger around the offending calls, all should be working like pre v5.10 versions.

sounds like back to normal ... still hoping for the future that on windows it will be just a warning
And i'm really glad that it is still possible to do it on windows, somehow

[netmaestro]

on Windows: "Warning: Using OpenWindow()/WaitWindowEvent() within threads is incompatible to GNU Linux and MacOS X!"

If it could be changed to the same warning level you get when you use a deprecated function like CreateGadgetList(), which only warns you without forcing you to change code, I think that would be good. Having to use Disable/Enable Debugger for code that works fine on Windows seems an awkward way to go forward. It is important that the debugger says something to prevent people from unpleasant surprises when porting code to another platform and this would please the most people imho. (or displease the least people, whichever way you see it)

[c4s]

If it could be changed to the same warning level you get when you use a deprecated function like CreateGadgetList(), which only warns you without forcing you to change code, I think that would be good.

+1
Although I could live with the slightly clumsy DisableDebugger/EnableDebugger workaround, this would really be the best solution from the (Windows) developer point of view!

[skywalk]

This also begs the question?
Why are threads not handled similarly on advanced OS's like GNU Linux and Mac OS X?

[MachineCode]

Just keep compiling it with version 4.5 and nothing will change. Nobody forces you to port it to the latest version.

But 4.5 doesn't have any of the bug-fixes of the new 5.10 release. That's the problem.

[freak]

Just keep compiling it with version 4.5 and nothing will change. Nobody forces you to port it to the latest version.

But 4.5 doesn't have any of the bug-fixes of the new 5.10 release. That's the problem.

Unless one of them explicitly stops you from finishing the program, what does it matter? Do you need a bugfix for a command that your program doesn't use?

jaPBe is still compiled with 3.94. It doesn't seem to require the latest 5.10 bugfixes.

[MachineCode]

Bug-fixes are not always just to "fix" something; they can be to add something that we're currently working around with either long-winded code, or other people's libs. For example, I need to use the PureSMTP lib from Gnozal to send emails, because the PureBasic mail lib lacks auth with 4.50. But it's there now in 5.10, which would be great for me to use and ditch Gnozal's lib (no offense to him). But I can't "upgrade" to 5.10 now unless I wrap all my OpenWindow and WindowEvent commands with DisableDebugger (which Fred even said is NOT recommended to do!). A real shame.

[c4s]

I can't "upgrade" to 5.10 now unless I wrap all my OpenWindow and WindowEvent commands with DisableDebugger (which Fred even said is NOT recommended to do!).

Yes, he said something like that. But shortly after:

We re-enabled the previous behaviour on Windows regarding event queue (as it should not impact new code), so with DisableDebugger around the offending calls, all should be working like pre v5.10 versions.

I think the best way of handling this (if it will not be changed from an error to a simple warning message - as requested by many ) is:

Code: Select all

Procedure _OpenWindow(Window, x, y, InnerWidth, InnerHeight, Title$, Flags=0, ParentID=0)
	Protected Result = 0

	DisableDebugger
	Result = OpenWindow(Window, x, y, InnerWidth, InnerHeight, Title$, Flags, ParentID)
	EnableDebugger  ; Will have no effect if debugger is disabled in compiler settings

	ProcedureReturn Result
EndProcedure

Procedure _WaitWindowEvent(Timeout=#PB_Default)
	Protected Result = 0

	DisableDebugger
	Result = WaitWindowEvent(Timeout)
	EnableDebugger

	ProcedureReturn Result
EndProcedure

Procedure _WindowEvent()
	Protected Result = 0

	DisableDebugger
	Result = WindowEvent()
	EnableDebugger

	ProcedureReturn Result
EndProcedure

[Fred]

Just keep compiling it with version 4.5 and nothing will change. Nobody forces you to port it to the latest version.

But 4.5 doesn't have any of the bug-fixes of the new 5.10 release. That's the problem.

Unless one of them explicitly stops you from finishing the program, what does it matter? Do you need a bugfix for a command that your program doesn't use?

jaPBe is still compiled with 3.94. It doesn't seem to require the latest 5.10 bugfixes.

Do you think we should change this to a warning on Windows ?

[MachineCode]

Do you think we should change this to a warning on Windows ?

+1

For window events too, obviously.

[auser]

Unless one of them explicitly stops you from finishing the program, what does it matter?

Does it matter if we could recommend PB to somebody else or get annoyed from all that screw you? Again: It matters because OpenWindow of PB 4.6 is bugged (especially if you use it with threads). And again it matters because we would like to get it as "feature" if it's just a warning. You told us use DisableDebugger. This was wrong. It was a real error and it did not came out without getting annyoing here it seems. Now it changes to a warning - so why not make it a warning then? Even if I get called paranoid because I'm not that magic to create a link to hidden threads: The OpenWindow bug is still there in PB 4.6. The bugfix for OpenWindow found it's way into 5.00 release. I know that because I asked Fred if PB 4.6 is stable enough to use and Fred already checked afterwards via SVN that the Bugfix for OpenWindow found it's way into 5.00. Fred even suggested me already to use 5.00 'windows' lib in 4.6 PB because there was just one change or so. I tried but that "mixed 4.6" did the same stuff like 5.00 afterwards (it throws an error) - however it would be better then using PB 5.00 with DisableDebugger. So back again to the topic (even if you see no reason for that - we would like to get it): If it's really save to use DisableDebugger now could you change the error to a warning - please?

[auser]

This also begs the question?
Why are threads not handled similarly on advanced OS's like GNU Linux and Mac OS X?

I agree. I'm not sure if there is any GUI in linux that does that same way like windows does. I checked QT and after reading lot of docs it seems to be similar (GUI have to be in main). At least there is some "Wine" that is running windows-apps in linux (and it calls itself to be not an emulator so should run "native"). So in theory it should be possible somehow I guess or all that programs that use the behaviour that worked in windows would not work with Wine... (to be honest I never checked if it works via wine)

[Fred]

It's indeed software only, if you run WINE or VMWare it will work. Native toolkits like QT, GTK and Cocoa doesn't support it, it's a design choice (and a all apps are running with this model, so it is not an issue).

[c4s]

Do you think we should change this to a warning on Windows ?

This sounded like you had changed your mind and wanted to switch the error to a (much more user friendly) warning message.

However the latest(?!) beta has just been released with the following note:

You can consider this one as final, as nothing should be change code wise [...]

I just tried creating a window inside a thread (on Windows with 5.10b8 of course) and this error message is still popping up... Does this mean that you don't want to change it anymore?

[auser]

Shame on me