Re: [Gnumed-bugs] <bug>: exited FreeDiams on Windows after being don

[Karsten Hilbert]

Hello Sebastian,

thanks for your report.

> user comment  : exited FreeDiams on Windows after being done with prescription
> 
> client version: 1.1.0

Given this:

> 2011-10-29 15:57:16  DEBUG     gm.shell 
> (c:\workplace\gnumed-client.1.1.0\build\pyi.win32\setup\outpyz1.pyz\gnumed.pycommon.gmshellapi::is_cmd_in_path()
>  #35): found [C:\Programme\FreeDiams\freediams.exe]
> 2011-10-29 15:57:16  DEBUG     gm.shell 
> (c:\workplace\gnumed-client.1.1.0\build\pyi.win32\setup\outpyz1.pyz\gnumed.pycommon.gmshellapi::detect_external_binary()
>  #111): found: executable in ${PATH}
> 2011-10-29 15:57:16  DEBUG     gm.meds 
> (c:\workplace\gnumed-client.1.1.0\build\pyi.win32\setup\outpyz1.pyz\gnumed.business.gmmedication::switch_to_frontend()
>  #345): calling FreeDiams in [prescription] mode
> 2011-10-29 15:57:17  DEBUG     gm.shell 
> (c:\workplace\gnumed-client.1.1.0\build\pyi.win32\setup\outpyz1.pyz\gnumed.pycommon.gmshellapi::run_command_in_shell()
>  #166): shell command >>>C:\Programme\FreeDiams\freediams.exe 
> --exchange-in="c:\dokume~1\basti\lokale~1\temp\gnumed\gm-e2to2w\gm2freediams-poofa1.xml"<<<
> 2011-10-29 15:57:17  DEBUG     gm.shell 
> (c:\workplace\gnumed-client.1.1.0\build\pyi.win32\setup\outpyz1.pyz\gnumed.pycommon.gmshellapi::run_command_in_shell()
>  #168): acceptable return codes: [0]
> 2011-10-29 15:57:17  INFO      gm.shell 
> (c:\workplace\gnumed-client.1.1.0\build\pyi.win32\setup\outpyz1.pyz\gnumed.pycommon.gmshellapi::run_command_in_shell()
>  #198): running shell command >>>C:\Programme\FreeDiams\freediams.exe 
> --exchange-in="c:\dokume~1\basti\lokale~1\temp\gnumed\gm-e2to2w\gm2freediams-poofa1.xml"<<<
> 2011-10-29 16:01:11  DEBUG     gm.shell 
> (c:\workplace\gnumed-client.1.1.0\build\pyi.win32\setup\outpyz1.pyz\gnumed.pycommon.gmshellapi::run_command_in_shell()
>  #201): os.system() returned: [0]
> 2011-10-29 16:01:11  INFO      gm.shell 
> (c:\workplace\gnumed-client.1.1.0\build\pyi.win32\setup\outpyz1.pyz\gnumed.pycommon.gmshellapi::run_command_in_shell()
>  #208): os.system() return value contained in acceptable return codes
> 2011-10-29 16:01:11  DEBUG     gm.cfg 
> (c:\workplace\gnumed-client.1.1.0\build\pyi.win32\setup\outpyz1.pyz\gnumed.pycommon.gmcfg2::get()
>  #314): option [internal::debug] found in source [internal]

and in particular this:

> 2011-10-29 16:01:11  DEBUG     gm.logging 
> (c:\workplace\gnumed-client.1.1.0\build\pyi.win32\setup\outpyz1.pyz\gnumed.pycommon.gmlog2::log_stack_trace()
>  #155): >>> execution frame [handle_uncaught_exception_wx] in 
> [C:\workplace\gnumed-client.1.1.0\build\pyi.win32\setup\outPYZ1.pyz/Gnumed.wxpython.gmExceptionHandlingWidgets]
>  at line 182 <<<
> 2011-10-29 16:01:11  DEBUG     gm.logging 
> (c:\workplace\gnumed-client.1.1.0\build\pyi.win32\setup\outpyz1.pyz\gnumed.pycommon.gmlog2::log_stack_trace()
>  #170):                    v = [Error 6] Das Handle ist ung??ltig
> 2011-10-29 16:01:11  DEBUG     gm.logging 
> (c:\workplace\gnumed-client.1.1.0\build\pyi.win32\setup\outpyz1.pyz\gnumed.pycommon.gmlog2::log_stack_trace()
>  #170):                    t = <type 'exceptions.WindowsError'>

I have no idea what we could do about it.

The error itself (6: handle invalid) is *extremely* generic
and can mean about anything.

My uninformed suspicion would be that it follows from the
client being run from a packaged executable. Which theory
could be tested by not doing so which would give us a morsel
of information whither to search.

Karsten
-- 
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346