Vista Issue with Compiled Script

[kpassaur]

Okay, here it goes, I have a compiled script that works fine on XP.

This same script works on Vista, unless it is compiled. If I compile it on either Vista or XP it fails to run properly on Vista but it still runs on XP (I did it on both just to check), however, if I just run it as a script from within MS on Vista it is fine.

The portion of it that does not work is it displays a menu with drop down lists. The lists keep on being reset to blank. (blank is the first index item)

When I first had issues, it was a syntax error on Vista that was not present on XP, I corrected this (I know it is correct as I can step through it or run it from within MS). So, I am looking for some ideas as to what it could be or where to look. The script is close to 800 lines so I did not post it all.

This is the portion that looks for changes

Show>Dialog2
Label>MainLoop
Let>Dialog2.Profileselected.fbinit=%settinsdir%\ProfileManager
GetDialogAction>Dialog2,result

//Compare to see if there is a change - this was changed to work with Vista
Let>testline1={Upper(%Dialog2.Profileselected%)}
Let>testline2a={Upper(%settinsdir%)}
Let>testline2b={Upper(%completestring%)}

Let>testline2=%testline2a%\PROFILEMANAGER\%testline2b%

IF>%testline1%=%testline2%
Goto>skiploadprofile
Endif
Let>update=YES

GoSub>getlist
Label>skiploadprofile
Let>Dialog2.Profileselected.fbinit=%settinsdir%\ProfileManager
ResetDialogAction>Dialog2
If>result=2,finish
If>result=1,Writesettings
If>result=5,DisplayHelp
Wait>0.5
Goto>MainLoop




//Below is the subroutine that updates the Dialog

SRT>getlist
IF>update=YES
Let>completestring=%Dialog2.Profileselected%
Else
Let>completestring=%selectedprofile%
Endif

Separate>%completestring%,\,filenamearray
Let>fileonly=%filenamearray_count%
Let>completestring=filenamearray_%fileonly%
StringReplace>%completestring%,.ini,,profilename

IfFileExists>%settinsdir%\ProfileManager\%profilename%_fieldslist.txt
Let>availablefields=%CRLF%
Let>k=1
Label>startgetlist
ReadLn>%settinsdir%\ProfileManager\%profilename%_fieldslist.txt,k,variablechoice
If>variablechoice=##EOF##,finishit
Separate>%variablechoice%,=,variable_read
Let>availablefields=%availablefields%%variable_read_1%%CRLF%
Let>k=k+1
Goto>startgetlist
Label>finishit
Let>DIALOG2.Dir1.ITEMS.TEXT=%availablefields%
Let>DIALOG2.Dir2.ITEMS.TEXT=%availablefields%
Let>DIALOG2.Dir3.ITEMS.TEXT=%availablefields%
Let>DIALOG2.File1.ITEMS.TEXT=%availablefields%
Let>DIALOG2.File2.ITEMS.TEXT=%availablefields%
Let>DIALOG2.File3.ITEMS.TEXT=%availablefields%
If>update=NO,skipupdate
Let>DIALOG2.Dir1.ITEMINDEX=0
Let>DIALOG2.Dir2.ITEMINDEX=0
Let>DIALOG2.Dir3.ITEMINDEX=0
Let>DIALOG2.File1.ITEMINDEX=0
Let>DIALOG2.File2.ITEMINDEX=0
Let>DIALOG2.File3.ITEMINDEX=0
ResetDialogAction>Dialog2
Label>skipupdate
Endif
End>getlist

Any ideas for a new way to debug something like this?

[Bob Hansen]

Your explanation does not make it totally clear to me about what is not working properly. Can you point out the specific line that produces unexpected result?

Anyway, here are some thoughts that come to mind.......
--------------------------------------------------

Have you looked at a log file to follow the flow?

Have you looked at the variables at various points in the flow, like just before refreshing Dialogs?

Include this in your script?
Let>_DUMP_VARS=1
to dump all variable names and values to log file.

------------------------

Timing could be different.
Can you set different Wait values or Timeout values or SK_DELAY values?

------------------------
Are you using variables for all paths vs. hardcoded paths, especially if system values are involved?

[kpassaur]

Thanks for the tips Bob.

This is what is happening. There is a dialog box thats goal is to write (or edit) an ini file. Now, some of the options that it writes come from a text file which is parsed. These options are in drop down boxes.

So, in a nutshell, when a user browses to an existing ini file, it opens a text file, reads it, relates it to the value in the ini file and sets the index position in a drop down box.

This all works fine in XP (compiled or not), in Vista it works when run from MS or when I step through it line by line. The difficulty is when it is compiled and run in Vista. What happens is it sets the index value to 0 in the drop down list and when the user changes it, it resets itself again to 0.

The difficulty I am having is that it works and everything runs great when I step through it. (makes it tough to debug when it works). Your time out idea is one that I had not thought of. However, the only timeout, waiting etc is in the loop that refreshes the dialog, not one that is sending any information.

The real tough pain about this is that my PC's security is set so that I cannot compile directly to anything in Program Files, so I have to compile it and then move it each time I want to test it.

That plus, when I compile something in Vista, on occasion it locks up MS without allowing the file to be saved. This actually happens quite frequently to me in Vista. If I don't save before compiling, I can lose all the changes I have made. When I do compile (the compiled scripts run fine even if it locks up), I just cannot save them afterwards and I have to use task manger to close MS.

The scripts are on a server that is mapped to be "My Documents" if that makes any difference. Other than that it is a pretty clean install of Vista Ultimate.

Any ideas on that?

[gdyvig]

Hi kpassaur,


Have your logfile print out the values of the directories used in your script, like %settinsdir% to make sure they are pointed to ones that exist on your target machine. In your other threads there was mention that some directories are in new locations under Vista.

You mentioned difficulties in compiling under Vista, if your compiled executable is loading anything make sure it was sucessful.

Will your compiled executable work if you run it from My Documents instead of Program Files? The compiled version of the script may be running into the same security issues as the compiler.


Gale

[kpassaur]

I have doubled the wait time to get it to run in Vista (thanks Bob). The wait time is for how often it goes through the loop that resets the dialog. It now has to be set to 1 second, which is pretty long when I think about it.

However, it will not run when in the program files directory in Vista. So, I would assume a security issue. But, UAC is off, it does not call or write anything in Program Files, so I really don't get it. Please remember when reading this that this is only a dialog that refreshes after reading a text file. The text file is located in a folder under roaming for the local user.

It is really at the point where I am starting to believe that my scripts should not be put into the Program Files Directory. It is much more work to do it and to what benefit. Well at least for the kind I write. Mine almost all deal with processing images in the background, they require numerous folders for temp images and some applications need to be run in the same folder as the temp file to do the processing. This makes it a real pain in Vista. On top of that since they run in the background most users want to run them as a service.

So, what is the real advantage of placing it in Program Files? I really cannot see one for a process that is going to be constantly run.

Any ideas on how to make it run in Program Files in Vista would be appriecated, especially with UAC being on instead of off. Currently it is off as I have a script that sends email and it cannot do so with UAC being on in the Program Files directory.

[gdyvig]

Hi kpassaur,

Would it be possible to separate out the background stuff that does not require a GUI to run as a service in the background under higher privileges? The GUI macro would need to communicate with the service via some intermediary, such as a file update.

Gale

[kpassaur]

Gale

That is what I have been doing, everything is broken down into modules and one module actually does the processing and it requires no user input.

What I am having issues with is really just this silly menu thing. What this particular module does is allow the user to create jobs. A job is a set of rules that are applied to tiff image files in a folder. The software, looks for an ini file, finds it, reads the folder name from the ini file and processes all the files in the folder based upon the rules. The rules themselves are contained in a text file as opposed to an ini file so that MS can read each line and apply as many rules as necessary.

Anyway, once finished it looks for the next ini file and continues in an endless loop. What it does when it finds a file is OCR it, extract text from it, rename it and place it in a folder. If it fails it puts it in a failed file folder and sends an email notification of the failure. Usually, my clients only process one kind of file (so cycling through the different types is not a big deal) and do 2-4 thousand of them a day.

So it is really just a system for automatically naming of files that come from a copier. My other ones to similar things such as do it by reading barcodes etc. (which works fine in Vista, even with UAC on).

I just don't get why it does this as it should not be a security thing, yet that is what it seems to be. I also don't get why my compiler in MS causes me on occasion to loose all if I don't save it before compiling. I am not speaking of compiling to some unusual location and the compiler is not failing, just the ability to return to the script afterwards. It locks up and I have to use Task Manager to close it. Any ideas on this as well would be appriecated.

They are really designed to work on a Work Station, however, most IT people do not understand imaging and what to do it on their server.

[Bob Hansen]

Can you turn UAC back on as normal default. Then have the macro disable UAC when it starts, and then reenable it again at the end of the macro?

There are a number of methods to do this. Google for "disable UAC command line". Here is an excerpt from: http://maximumpcguides.com/windows-vist ... nd-prompt/

Disable UAC from the Command Prompt

1. Type cmd in the search box in the Start Menu.
2. Right-click cmd in the search results and select to Run as administrator.
3. Type the following in the command prompt and press enter:

C:\Windows\System32\cmd.exe /k %windir%\System32\reg.exe ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v EnableLUA /t REG_DWORD /d 0 /f
4. Restart your computer.

Enable UAC

To enable UAC simply type the following in the command prompt or search box in the Start Menu and press enter:

C:\Windows\System32\cmd.exe /k %windir%\System32\reg.exe ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v EnableLUA /t REG_DWORD /d 1 /f

You may have to modify those lines to work as Macro Scheduler Run Program commands,

[kpassaur]

First off thanks Bob and Gayle.

I have figured it out and hopefully this will benefit many.

Please keep in mind the Dialog Appeared but would not refresh correctly when run from a compiled version with the compiled script located in the Programs File folder.

I tried it with both UAC on and off and recieved the same results. Then I browsed to it and ran it directly and it worked. Normally it was called from another script (menu program) created with MS.

So the fix was to call it as a command line program. So it is now

Let>RP_WAIT=0
Let>RP_WINDOWMODE=0
ChangeDirectory>%ProgramFolder%\eDocFile\File by OCR\Outputjobs
RunProgram>CMD /c "OutputjobSetup.exe"

opposed to
RunProgram>OutputjobSetup.exe

and it works with both UAC enabled and disabled. So, just a suggestion, always call something from the command line as opposed to directly.