Please allow OpenWindow inside threads

[kandl]

HI

I have multiple projects that uses OpenWindow inside a thread. They function as background processes and have their independent message processing loop. One example is an OpenGL application that spawns a drawing thread separate from the main window, it opens another window in its own thread to probe the extension list. I also have property windows that are non-modal and they require separate event processing as well. All of this functions perfectly in 4.50. I suggest that purebasic change the ERROR to a WARNING because it severely limits the way applications are developed.

Thanks!

[luis]

It's not a bug, in any case.

http://www.purebasic.fr/english/viewtop ... =3&t=52166

[rsts]

+1

Who's going to rewrite all the useful code snippets that use openWindow in a thread?

[infratec]

At least there should be a 'MessageRequester()' which is not modal
and can be closed by second call or a 'CloseMessageRequester()'.

Like this:

Code: Select all

MessageRequester("Info", "Please wait ...", #PB_Window_NotModal)
DoSomething()
CloseMessageRequester()

If I have to do such a thing via PostEvent() and ...
it is a lot of overhead and a lot of work

Or I have to use always

Code: Select all

DisableDebugger
Win = OpenWindow()
EnableDebugger
TextGadget()
DoSomething()
CloseWindow(Win)

Bernd

[rsts]

Not necessarily just messageRequester. Several "requester type" snippets rely on threaded behavior to accommodate input.

[jassing]

+1 -- it should be a warning..

[netmaestro]

The problem is it won't work on other OS.

If it works without problems on Windows but causes issues on the other platforms, I think PureBasic for Windows should allow it without any warnings at all and do something different for the other OS's. It's all well and good to be crossplatform but if targeting multiple platforms means crippling the Windows version to accommodate the other operating systems then we're not doing it right. Just my opinion, worth the standard two cents.

[skywalk]

I agree. Better approach is to maximize OS support and let documentation do the rest.
Elements of this are already in play with Callbacks, OnError Lines, etc.
http://www.purebasic.com/documentation/ ... cific.html

[Fred]

Then you will get some angry comments when someone have a 100% working PB program on Windows and want to do a Linux or OS X version as it won't work at all. We enforce it, but if you really want, you can put some disabledebugger around the calls.

[PMV]

Then you will get some angry comments when someone have a 100% working PB program on Windows and want to do a Linux or OS X version as it won't work at all. We enforce it, but if you really want, you can put some disabledebugger around the calls.

Do you remember any commend about that?
I just remember threads where people are confused, why it is not working ...
and they just want to know what they have done wrong ... after you
have explained it, it was ok again, just angry about that they have
used time for programing something wrong ... so it could
be improved in that way to tell them that it will not work on linux/ mac.
A warning on windows instead of an error is the better choice.
On linux and mac it should be still an error.

There are always people who complain about something, if you can
stand this every-month-topic, still your choice
But for me, there is no reason behind this "error".

MFG PMV

[luis]

I admit didn't even try it, but if the problem is only reported by the debugger, and if you can use the enable/disable debugger as Fred explained to suppress the error on Windows I don't think this is a problem at all.
It's a remainder that on another os could not work at all and you should find another way if you want port your program on another os.

[netmaestro]

if you can use the enable/disable debugger as Fred explained to suppress the error on Windows I don't think this is a problem at all.

Sure, fair enough. I like to send messages to the main thread myself and the new PostEvent() will suit me fine.

[kandl]

Thanks Bernd!

The debugger also disallows WaitWindowEvent() and WindowEvent() from executing from inside a thread.

[c4s]

The debugger also disallows WaitWindowEvent() and WindowEvent() from executing from inside a thread.

Yes. Because of that I'm using something like:

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

	ProcedureReturn Result
EndProcedure

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

	DisableDebugger
	Result = WaitWindowEvent(Timeout)
	EnableDebugger

	ProcedureReturn Result
EndProcedure

Just replace all "OpenWindow(" with "_OpenWindow(" etc. and PureBasic should work as before.

[CalamityJames]

I would like to add my voice to those calling for a less heavy-handed approach to opening a window in its own thread. Clearly, not being able to do it in Linux or the Mac OS is an important limitation which those writing cross-platform programs need to be aware of. However there are other important limitations in some PureBasic commands. They are dealt with in the documentation and that is the proper place.
My own PureBasic is set up with only the compiler for Windows active. I frequently use direct calls to the Windows API which obviously means my programs can run only in Windows. Despite this, I am instructed that I cannot open a window in its own thread! I can turn off the compiler as mentioned, but I am not fond of this inelegant solution. I don’t think it should be necessary.