Remy!
I think I've got it...
..I see where it fails but I could not reproduce nor do I see why you've got the invalid whole number
I added a few verification to check not going into an invalid whole number into this part of the code as well. Also added routine if the input file could not be read "already open" or other errors ( if ffmpegh started well with parameters but the radio button isn't on ! them, click on it to display latest messages)...
Looks to me like the program is not using a fully qualified DLL_LIST filename due to no fault of it's own. It seems this is the result of the WPS program object defintion I created, where I have the following:
PATH AND FILENAME = G:\UTIL\MISC\DLL_LH.EXE
INPUT_PARAMETERS = -c usr_dll_list.dlh
WORKING_DIRECTORY = (blank)
Here is why I say that:
1) start the program with the input command line as follows '
The intial load goes fine, as does the initial invocating of something like 'Query', the results are:
...
Processing... with options : -q usr_dll_list.dlh 1
Dll(s) path : "G:\USR\DLL"
Path to DLL(s) found, process will continue and try loading DLL(s)
*Information* found module with handle x"3D210000"
[G:\USR\DLL\SNAPWRAP.DLL]
DLL(s) query handle done
...
...but afterwards any attempts to use 'Query' or 'Free' all result in the following error output:
...
** ERROR ** an error occured reading input file including dll list
Verify input file for possible cause :
- File aleady open
- File size = 0
- First line has an incorrect path syntax
(path must be specified between double quotes e.g. "C:\usr\lib")
- Other possible issue
>>>> current request aborted
...
NOTE: whatever way you're handling the trap is also preventing (here on my machine) me from going back to the GUI window itself to actually close the program, instead I use 'kill' which does successfully close it.
2) re-do the start, same input command line, but now I actually modify the text-field which stores the input parameter the program was originally started with, so instead of just using the filename (usr_dll_list.dlh) I now use a fully qualified name so that includes the complete path (g:\util\misc\usr_dll_list.dlh), this produces the following successfull output:
Processing... with options : -q g:\util\misc\usr_dll_list.dlh 1
Dll(s) path : "G:\USR\DLL"
Path to DLL(s) found, process will continue and try loading DLL(s)
*Information* found module with handle x"F71D0000"
[G:\USR\DLL\SNAPWRAP.DLL]
DLL(s) query handle done
The way to get around this is to modify the WPS Program object to set the INPUT_PARAMETER to show a fully qualified path, which I tested and am happy to report that it works.
I did not try setting the WORKING_DIRECTORY in the Program object to see what impact, if any, it had.
Alright, I would say this works. Unless there were any other changes in this test build (other than the DEBUG stuff) I think I can go back to using the previous release and just use a fully qualified pathname as the input parameter.
Thanks Remy!!!