I have a short script (below) which I use to launch my program (Campaign
Cartographer 3). If I run this from the terminal, I have no problems
but if I attach it to a launcher on the panel then as soon as I move the
mouse into the window, it closes down without any error popping up - but
*only* if the program runs in a maximised window; if I start the program
in a smaller than maximised window, it works fine, even if I then switch
to maximised.
Obviously, running it from a launcher means that I have no terminal
output to give me any leads, so I'm hoping someone can shed some light
on this peculiar behaviour.
Many thanks,
David Shaw
OS Ubuntu 10.04
Wine version 1.3.26
lspci output VGA compatible controller: nVidia Corporation C67
[GeForce 7000M / nForce 610M] (rev a2)
Subsystem: Hewlett-Packard Company Device 30ea
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 16
Memory at f5000000 (32-bit, non-prefetchable)
Memory at d0000000 (64-bit, prefetchable)
Memory at f4000000 (64-bit, non-prefetchable)
[virtual] Expansion ROM at 80000000 [disabled]
Capabilities: <access denied>
Kernel driver in use: nvidia
Kernel modules: nvidia-current, nvidia-173, nvidiafb,
nouveau
========== Script Starts ==========
#!/bin/bash
export WINEPREFIX='/home/david/.wine-prefix/CC3'
cd $WINEPREFIX/drive_c/Program\ Files/ProFantasy/CC3
wine fcw32.exe
=========== Script Ends ===========
Odd window behaviour
I'm not really sure where the problem lies, but have you tried doing like...
?
The shell script should stop running and just leave the Wine process running
Code: Select all
wine fcw32.exe &
The shell script should stop running and just leave the Wine process running
Odd window behaviour
Well, that's the problem I have. With no output, I have no idea what
the problem could be
I doubt that the problem lies either with my script or with Wine itself
- after all, run from the terminal everything is hunky-dory - but you
never know and I believe in trying to eliminate the simpler things first.
Anyway, the only noticeable change to the program's behaviour after
doing as you suggest is that there is now a brief but noticeable delay
between moving the cursor into the window and the program quitting.
It's not a major biggie; I have a work around. It's just an irritating
behaviour that didn't used to happen (back around about Wine 1.3.20) and
I'd rather not have happening.
David Shaw
On 21/08/11 19:38, doh123 wrote:
the problem could be

I doubt that the problem lies either with my script or with Wine itself
- after all, run from the terminal everything is hunky-dory - but you
never know and I believe in trying to eliminate the simpler things first.
Anyway, the only noticeable change to the program's behaviour after
doing as you suggest is that there is now a brief but noticeable delay
between moving the cursor into the window and the program quitting.
It's not a major biggie; I have a work around. It's just an irritating
behaviour that didn't used to happen (back around about Wine 1.3.20) and
I'd rather not have happening.
David Shaw
On 21/08/11 19:38, doh123 wrote:
I'm not really sure where the problem lies, but have you tried doing like...
Code:
wine fcw32.exe&
?
The shell script should stop running and just leave the Wine process running
Odd window behaviour
On Sun, 2011-08-21 at 13:38 -0500, doh123 wrote:
program from a wrapper script:
---------------Start of script---------------
#!/bin/bash
export WINEDEBUG=trace+file
export WINEPREFIX=$HOME/.wineprefixname
cd $HOME/path/to/directory/containing/fcw32.exe
wine fcw32.exe 2>$HOME/fcw32.log
----------------End of script----------------
Put this script anywhere, commenting out the WINEDEBUG line if you don't
need it and changing the WINEPREFIX and 'cd' lines to match your setup.
Make the script executable: "chmod u+x scriptname" and you can test run
it from the command line.
Once its working OK and the debug information is ending up in your login
directory in a file called fcw32.log, you can make a launcher that runs
the *script* rather than the bare "wine fcw32.exe" command. This will
put the trace you need in the same place as when the script was run from
the command line.
All wine tracing and error reporting is sent to stderr, so the log file
is captured by redirecting channel 2.
Its most important that the log file name is prefixed by $HOME or the
log file will end up wherever you change directory to before running the
program.
For what its worth, I always use this approach to running programs under
wine because the convenience of debugging the wrapper script in a
terminal window vastly outweighs the work needed to create the script.
Martin
I was about to suggest exactly the opposite. Instead, try running theI'm not really sure where the problem lies, but have you tried doing like...
Code:
wine fcw32.exe &
program from a wrapper script:
---------------Start of script---------------
#!/bin/bash
export WINEDEBUG=trace+file
export WINEPREFIX=$HOME/.wineprefixname
cd $HOME/path/to/directory/containing/fcw32.exe
wine fcw32.exe 2>$HOME/fcw32.log
----------------End of script----------------
Put this script anywhere, commenting out the WINEDEBUG line if you don't
need it and changing the WINEPREFIX and 'cd' lines to match your setup.
Make the script executable: "chmod u+x scriptname" and you can test run
it from the command line.
Once its working OK and the debug information is ending up in your login
directory in a file called fcw32.log, you can make a launcher that runs
the *script* rather than the bare "wine fcw32.exe" command. This will
put the trace you need in the same place as when the script was run from
the command line.
All wine tracing and error reporting is sent to stderr, so the log file
is captured by redirecting channel 2.
Its most important that the log file name is prefixed by $HOME or the
log file will end up wherever you change directory to before running the
program.
For what its worth, I always use this approach to running programs under
wine because the convenience of debugging the wrapper script in a
terminal window vastly outweighs the work needed to create the script.
Martin
?
The shell script should stop running and just leave the Wine process running
Odd window behaviour
Thanks for that, Martin. I was already using the wrapper script idea
(from a suggestion you made in an earlier thread, in fact) but was
missing how to get the output into a file (I've only just started
learning how to use Bash properly).
The last few lines of the output are below - the full output is
available at http://tinypaste.com/1de560 for anyone who's interested -
which, to my untrained eye seems to implicate the X server. I do find
it interesting, though, that this problem *only* manifests when calling
the script from a launcher on the panel.
David Shaw
trace:file:RtlDosPathNameToNtPathName_U
(L"C:\\windows\\system32\\user32.dll",0x32edbc,0x32edd0,(nil))
trace:file:RtlGetFullPathName_U (L"C:\\windows\\system32\\user32.dll"
520 0x32eaec 0x32edd0)
X Error of failed request: BadValue (integer parameter out of range for
operation)
Major opcode of failed request: 53 (X_CreatePixmap)
Value in failed request: 0x0
Serial number of failed request: 14538
Current serial number in output stream: 14581
On 21/08/11 21:05, Martin Gregorie wrote:
(from a suggestion you made in an earlier thread, in fact) but was
missing how to get the output into a file (I've only just started
learning how to use Bash properly).
The last few lines of the output are below - the full output is
available at http://tinypaste.com/1de560 for anyone who's interested -
which, to my untrained eye seems to implicate the X server. I do find
it interesting, though, that this problem *only* manifests when calling
the script from a launcher on the panel.
David Shaw
trace:file:RtlDosPathNameToNtPathName_U
(L"C:\\windows\\system32\\user32.dll",0x32edbc,0x32edd0,(nil))
trace:file:RtlGetFullPathName_U (L"C:\\windows\\system32\\user32.dll"
520 0x32eaec 0x32edd0)
X Error of failed request: BadValue (integer parameter out of range for
operation)
Major opcode of failed request: 53 (X_CreatePixmap)
Value in failed request: 0x0
Serial number of failed request: 14538
Current serial number in output stream: 14581
On 21/08/11 21:05, Martin Gregorie wrote:
like...On Sun, 2011-08-21 at 13:38 -0500, doh123 wrote:I'm not really sure where the problem lies, but have you tried doing
I was about to suggest exactly the opposite. Instead, try running the
Code:
wine fcw32.exe&
program from a wrapper script:
---------------Start of script---------------
#!/bin/bash
export WINEDEBUG=trace+file
export WINEPREFIX=$HOME/.wineprefixname
cd $HOME/path/to/directory/containing/fcw32.exe
wine fcw32.exe 2>$HOME/fcw32.log
----------------End of script----------------