Please allow OpenWindow inside threads

[rsts]

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.

I agree. However if the current approach somehow makes fred and freak's lives easier and allows them to continue to make all the wonderful improvements they've been making lately, I'll happily accept their answer.

[auser]

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.

Fred the result of following your instructions of PB 4.5 docu is code that result in an error now - if you ever considered to create a linux version or not. In both cases a "OpenWindow(some_dumb_failure_debug_me_please)" is now outside the scope of the debugger. Your instruction was if you use OpenWindow in a thread then even WindowEvent have to be in a loop in that thread. It's not the job of a windows-programmer to reinvent the wheel or to check if that could be buggy in your choosen linux-gui-environment. Your previous instruction was a clear rule and worked well in windows and now you drop all those guys that followed exactly that instruction to the "unsupported"-edge. So why do you consider regarding angry guys in future? That's pretty sad to read. What's with the guys from here and now? It's not always that easy to change now an independed modular design to some code that does it all in one main. If I'm going to do that at all my code based on the previous docu it would easy take weeks or months of recoding. So I think it's at least fair to follow now that tiny wishes of that trapped ones. If you ignore a compilier-warning you have more than you had in the past where you got just wrong instructions through the docu. No warning no error - nothing than a "wrong" docu (that is not that wrong anyway coz it's working well on windows that way).


Greetings,
auser

[freak]

Its just a debugger warning. Get over it.

Btw, you don't have to change your "I followed the 4.5 documentation"-program at all. Just keep compiling it with version 4.5 and nothing will change. Nobody forces you to port it to the latest version.

[auser]

Its just a debugger warning.

Did you ever read this thread or care regarding the users here? It's no warning it's an error. That's the point and the reason for this thread.

Nobody forces you to port it to the latest version.

You made a mistake and we need to spoon it? It was working fine in windows as you've written in your previous doc in windows. So where is the problem? Users that followed your instructions did not get a warning and no working linux version anyway. Now everybody that followed your instructions gets drop to the unsupported edge. Thx. And thanks for that great hint of "not beeing forced to update" anyway. At least good to see how you handle this.

[jassing]

Nobody forces you to port it to the latest version.

No no one does, but since PB regularly "breaks" code, If there is a new feature, or bug fix we need, it requires us to spend lots of time 'fixing' things -- either by maintaining multiple copies of PB, or compiling parts of a program into a dll in an older version then using the newversion..
If that's hte official stance of "Screw you, live with it" PB should make it easier to compiler portions into a lib file and link in automatically by selecting which version of PB to use on a particular source file...

Honestly, I'm kind of shocked at the terse language, especially when you say "it's a warning" when it isn't.

Most languages make a point of trying to maintain backward compatibility, with the "stop at a single error" compile mode, upgrading to new versions of pb sometimes is a painstaking process ..

Why respond at all if that's the official stance? Why not just say "that's the way it is, we're not going back" to all such complaints? Why listen to users?

[freak]

Its just a debugger warning.

Did you ever read this thread or care regarding the users here? It's no warning it's an error. That's the point and the reason for this thread.

I misspoke, sorry. I meant "error". Even the debugger errors are nothing more than a hint to the programmer. You can ignore the debugger if you want (DisableDebugger) and nothing will be different than in earlier versions. The actual library command works as it did before. You are making this a bigger deal than it really is.

And yes, you are not forced to update. What is wrong with finishing a program in the PB version where it was started? Its not like the mere fact that a new version is released makes the old one unusable. You can have as many versions as you like in parallel.

Also, keep in mind that I too maintain a 100.000 line PB program (the IDE) that I have updated to every single PB version since its creation in 3.81. The changes between the versions are really not as big a deal as you people make it sound.

[auser]

Even the debugger errors are nothing more than a hint to the programmer.

That's not true. A warning is a hint. An error stops you to continue without further investigation (either a fix if it was a failure done by you or workaround).

and nothing will be different than in earlier versions.

For sure it is different. You don't debug that lines and usage is changed as well if you try to use as less variables as nessesary:

Code: Select all

; PB old
Procedure ProgressWindow1(*unused)
  Protected pb_window1
  Protected pb_window2
  pb_window1 = OpenWindow(#PB_Any,0,0,120,40,"test1")
  pb_window2 = OpenWindow(#PB_Any,0,0,120,40,"test2",#PB_Window_ScreenCentered,pb_window1) ; ParentID is not a valid WindowID() - ops forgot WindowID() good to have a debugger that told me
  If pb_window2
    Repeat
      Select WindowEvent()
        Case #PB_Event_Gadget
        Case #PB_Event_CloseWindow
          CloseWindow(pb_window2)
          ProcedureReturn(0)
      EndSelect 
    ForEver 
  EndIf 
EndProcedure 

Code: Select all

; PB 5.0 - don't run ... it's bugged
Procedure ProgressWindow2(*unused)
  Protected pb_window1
  Protected pb_window2
  Protected event_var
  DisableDebugger
  pb_window1 = OpenWindow(#PB_Any,0,0,120,40,"test1")
  pb_window2 = OpenWindow(#PB_Any,0,0,120,40,"test2",#PB_Window_ScreenCentered,pb_window1) ; Hopefully this mistake would not occure in some code with many thousands of lines - could be fun to debug if something else makes unexcpected stuff afterwards
  EnableDebugger
  If pb_window2
    Repeat
      DisableDebugger
      event_var = WindowEvent()
      EnableDebugger
      Select event_var
        Case #PB_Event_Gadget
        Case #PB_Event_CloseWindow
          CloseWindow(pb_window2)
          ProcedureReturn(0)
      EndSelect 
    ForEver 
  EndIf 
EndProcedure 

You are making this a bigger deal than it really is.

Changing an error to a warning is no big deal. Staying on an older bugged version or make your debugger blind on various parts of your code is something fully different. Why are you always stopping to tell us it's nothing?

What is wrong with finishing a program in the PB version where it was started?

You remember the OpenWindow bug I reported that nobody was willing to hear at first? The threads finally got 4 or 5 pages and seems silently gone now. I could not find it anymore. Did you delete it? At first I reported a reproduceable bug in OpenWindows in Windows PB and afterwards a bug with OpenWindows and threads in linux. After lot of investigation from my side to show you how to reproduce the bug in windows (and fighting against windmills - coz most was not willing to hear... until I finally was able to show you crazy jumping windows) there came a fix to Windows-Version of PB. The Linux-version did not get fixed to work like written in PB doc but the fault was declared to be on OS side. But it's no bug in the GUI of linux. So it's even not linuxs fault.

are really not as big a deal as you people make it sound.

And why do you think your program is the same as everybody else program? Changing independent windows that lived on their own and merge it into a big main is a big deal. You compare apples and banana. It's not like dropping one command or add few parameters - it's a full rewrite of your design (merging loops, variables, passing events from one to other threads that did not have to care regarding each other to that point). I already considered to move the parts that was working in threads into different processes and find a way to move security sensitive data to other process. I even cosidered to port it to QT. But while considering all that much work I thought a few times -> "Why is it necessary that this must be an error and could not be a warning?!". And I found other users here that +1 a warning instead an error as well. For sure you could find a sollution if you invest a lot of time. But it's even possible to change the error to a non-stoping non-debugger-jamming warning. Which users would get angry regarding the change? I was one of the few (or seriously the first) that used OpenWindows and threads in linux and found out that it did not work like it was written in the docu which I read while coding in windows. I reported it as PB bug and got as answer that it's a limitation of that linux-gui. Well to late for me. I thought I could use 1:1 in linux. Was even my fault for sure. I had to test it more often while coding on windows. There was no warning in previous versions of PB that would inform me that my program would be a Windows-Only if I use it that way. The PB-error is the worst sollution for me now. I never get a working-linux version with OpenWindow in threads it seems (it's limited by the design of the linux-gui) I even could not use the windows-version that way anymore without jamming the debugger.

[PMV]

Changing an error to a warning is no big deal. Staying on an older bugged version or make Your debugger blind on various parts of your code is something fully different.

Thats what i have a problem with ... it is not a big deal to have a not
well looking code, but to disabling the debugger on maybe some important
parts can be a hug waist of time ... .


But i just repeat myself ... and you will repeat yourself again ... at the end i
just wanted to ask if you can change this to stop auser to post here, so you
doesn't need to waist so much time on reading and answering

MFG PMV


hint: just a jock

[Fred]

The same discussion again, you're telling us all is bad without bringing a valid solution. We are working to find solutions not only for you, but for all users. BTW, we don't delete threads, so stop your paranoïa trip, it was moved to bug forum then moved to an hidden to a fixed forum. If you have any issues with that, contact me via PM.

[Fred]

BTW, i was wrong when telling than disabledebugger is enough, as now all events stack up in the main thread, so event loop in threads won't behave correctly anymore. So it's really an error and not a warning. If you can't change your code, you can still use PureBasic 4.61 available in the museum version of your online account, and again sorry for the inconvenience. We believe than enforcing this will make PB better overall for the future.

[PMV]

[...] now all events stack up in the main thread, so event loop in threads won't behave correctly anymore.

You mean all calls to WindowEvent() outsite of the main-thread will always be empty and are no longer working in windows, too?

BTW, i was wrong [...]

Just remembers me that you are somehow a human, too.

[Fred]

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.

[skywalk]

Yay!

[auser]

We re-enabled the previous behaviour on Windows regarding event queue (as it should not impact new code)

Sounds like showstopper changed to warning yet again on Windows-OS. So how's the chance to get a debugger-warning instead an error (like requested in this thread) as well now?

[Danilo]

So how's the chance to get a debugger-warning instead an error (like requested in this thread) as well now?

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