Windows 7 libraries and FileOpenDialog

[Dana]

I'm having troubles with a compiled Autoit script on one machine, but not two others. It works fine on an XP laptop and on one Win7 laptop, but not on the other Win7 laptop. It's the same user on all machines, same .exe, same .ini.

First, the program does an ini read to retrieve, among other things, two data directories, which are shared folders on another computer:

;Read ini file
$datadir = IniRead("shaftlength.ini", "Directories", "datadir", ".\")
If (StringRight($datadir, 1) <> "\") Then $datadir = $datadir & "\" ; add trailing backslash if it's missing
$paramdir = IniRead("shaftlength.ini", "Directories", "paramdir", ".\")
If (StringRight($paramdir, 1) <> "\") Then $paramdir = $paramdir & "\" ; add trailing backslash if it's missing

The ini file looks like this:

[Directories]
datadir=\\solenoidassy\shaftlength\jobfiles
paramdir=\\solenoidassy\shaftlength\Parameters

Next, some parameters are read from a file in $paramdir. This works correctly on all 3 computers. A GUI then opens to let the user create a new data file or reopen an old one (not complete code here):

While 1
    $guimsg = GUIGetMsg()
Select
Case $guimsg = $okbutton
$job = GUICtrlRead($jobinput)
; irrelevant stuff snipped

Case $guimsg = $reopen
$job = GUICtrlRead($jobinput)
$jobfilename = $datadir & $job & ".csv"
If Not FileExists($jobfilename) Then
    $jobfilename = FileOpenDialog("Select Job File", $datadir, "Job files (M*.csv)")
    If (@error == 1) Then ContinueCase
EndIf
If FileExists($jobfilename) Then
    $job = StringReplace(StringTrimRight($jobfilename, 4), $datadir, "")
    $hfile = FileOpen($jobfilename, 0)
    ; more stuff snipped, the file is opened and read
EndIf
EndSelect

Wend
GUIDelete()

If Not FileExists($jobfilename) Then
    ;$hfile = FileOpen($jobfilename, 1) ; open file to write header line
    $headerline = $partnum & "," & $gageA & "," & $gageB & "," & $clearance & "," & $comment
    FileWriteLine($jobfilename, $headerline)
    ;FileClose($hfile)
    $linenum = 0
EndIf

; more snipped, the file is opened for writing
; and data is written as received from a serial
; connection... that part isn't the problem

There's an input box in the GUI for the user to enter the job number, from which the filename is created. If

The problem occurs when the actual data file (in $datadir) is opened. The user either enters a job number and the program creates the data file from scratch, or reopens an existing file. If the user chooses "reopen", it opens the old file, if a valid job number is entered, or uses FileOpenDialog to let the user select the file from $datadir. If the file doesn't exist, it is created when the user clicks the OK button.

On the problem computer, instead of the fileopendialog starting in $datadir, it opens in Libraries on the local computer, while on the other computer it opens properly in $datadir. The user can browse to the correct location ($datadir), select, and open the file, and the existing data is properly read. If it's a new job, there are no errors, but the file doesn't seem to get created... anywhere. I have to check if edits to the file get saved when it's browsed to and reopened (the computers are in another building, so I can't check it right now).

As far as I know both of the Windows 7 computers should be identically set up (I didn't do the initial setup), with identical copies of both the exe and ini files. Same user on both computers, so it shouldn't be a permissions issue.

[Dana]

Well, I solved it... sort of. I compared the two computers, and they were 99% identical (except that one didn't work). The only difference is that one computer had another user listed (that wasn't logged in, though). Nothing worked, until I mapped a network drive to the jobfiles folder. At that point it prompted me for a username and password, and I used the same username that was logged in the computer. I changed the ini file to point to the mapped drive, and the program worked... and continued working even after I disconnected the network drive, changed the ini file back, and restarted the computer.

Some sort of credentials thing, I guess... but exactly what, I don't know.