Bug still exists in rc-1.

It usually hangs for a bit over 15 minutes, which is close to 1024 seconds.(I'm not patient enough to time it exactly ;) )

Please attach a WINEDEBUG=win,event,x11drv trace of the problem (no need to let it run for 15 minutes, just kill it once it's hung).

Created attachment 13198 [details]
Log from winedebug=win,event,x11drv

The run in the attached log file was run under rc1, and consisted of opening the program, moving the mouse to the title bar of the 3d window and clicking on the title bar, at which point the flashing crossed-arrow cursor appeared and the keyboard and mouse buttons were not accepting input. I double-clicked on the background, with no effect, so I killed X with crtl-alt-backspace.

Thanks, it looks like the app is constantly asking for the window to be moved, not sure why. Could you please get a WINEDEBUG=relay,message,event,x11drv trace?

Hopefully this is what you wanted-it is about 2.1 GB unpacked!

The log is here:

http://rschaffter.home.comcast.net/~rschaffter/log.txt.bz2

Same scenario as above, except I didn't double-click on the background window before I killed X.

Created attachment 13209 [details]
Hack to wait for size/move to finish

The problem is the app is sending an endless stream of WM_NCLBUTTONDOWN messages as long as the mouse button is pressed. Does this patch help?

With the patch applied, the 3D window moved when the title bar was clicked and dragged, and stopped moving when the mouse button was released.  However, the cursor remained the flashing cross arrow cursor and the keyboard and mouse buttons were locked out for approx. 45 minutes, at which point the cursor stopped flashing. At this point moving the mouse would move the window (the pointer was not over the window title bar), but clicking on the background released the window and input was possible again.

Created attachment 13254 [details]
Improved hack

This may work better.

It does indeed-it works perfectly! :D

Good Work!!

I just discovered that the patch is apparently specific to the development environment of openSUSE 10.3-I tried recompiling the patched Wine 1.0 under the openSUSE 11.1 Release Candidate, and the resulting binary crashes.  However, he  binary compiled under openSUSE 10.3 runs fine, as does an unpatched binary compiled under 11.1.

Created attachment 17627 [details]
Console output from Poser with Patched Wine under openSUSE 11.1 RC

Here is the console output from running Poser under Wine 1.0 patched per this bug and compiled under openSUSE 11.1 Release Candidate.

Created attachment 18261 [details]
Hack modified for Wine 1.1.11

I didn't figure out why the patched Wine 1.0 would crash Poser when compiled on openSUSE 11.1.  

However, looking at the patch,  I noticed that the  /dlls/winex11.drv/keyboard.c of Wine 1.1.11 incorporates that part of the successful patch, so I clipped it out of the diff, leaving the patch to /dlls/winex11.drv/window.c intact. 

Patched 1.1.11, compiled and Poser runs fine!

The issue still exists in Wine 1.1.12, 1.1.13, and 1.1.14.  The modified hack continues to work.

The issue still exists in Wine 1.1.15-1.1.21.  The modified hack works in 1.1.21. (I hadn't tried the intermediate versions)

The issue still exists in Wine 1.1.22-1.1.26.  The modified hack continues to work.

Somewhere along the line ctrl-alt-esc started working for the unpatched Wine when it hung.  It usually takes at least three presses to get a functioning Jolly Roger cursor, and then it can be killed.  Unfortunately there's no option to save one's work... ;)

Poser seems prone to several display problems under X Windows. I find that moving the Nvidia display settings to "fastest" helps with many issues, but does not remove them.

I have run Poser under OpenSUSE 10.3, Ubuntu 8.10, and Ubuntu 9.10 with little difference between hosts. I keep up with the latest Wine development version - currently 1.1.26

It appears that if you simply click on the window, move it, then click again it will work - MOST of the time!

Sequencing of the display windows on the screen seems arbitrary with message windows often ending up hidden beneath other windows. This occurs on Windows installs a swell, but this problem is clearly much more prevalent under Wine.

There are also problems in that many of Poser's internal names (e.g. object names) are case insensitive and thus are inconsistent when invoked from different places. This is mostly a library issue, but can affect internal process calls as well.

This is your friendly reminder that there has been no bug activity for 6
months. Is this still an issue in current (1.1.44 or newer) wine?

The bug still exists in Wine 1.1.44.

I haven't tried the hack with anything past 1.1.26...

Still a bug in current wine?

Over 1 year since last reminder, no download, resolving abandoned.

Actually a variant of that hack is in the tree now, so it's probably fixed.

I had moved my 3D work to a Windows machine, so I reinstalled Poser 7 (current version is Poser 9) and discovered it does not run in wine 1.5.12; I get a blank grey screen with no console output, but that's obviously a different issue, and not worth perusing for a program two versions out of date.

Poser 8 runs reasonably well, but it uses a completely different interface architecture, so it doesn't reflect onto this bug.  I trust in Alexandre's assessment that it is fixed...

On a whim I installed the MS Visual C 2005 Runtime and it works, and the bug is indeed squashed.  :)

Closing bugs fixed in 1.5.13.