My PC too fast or what??

My app uses ShellExecute to call another exe which
generates a text file. I then open up this file using
the following syntax:
"Open ImportFile For Input As #iFileNum
Do While Not EOF(iFileNum)
DoEvents ' allow user escape
Line Input #iFileNum, sLineRead
...."
Sometimes it reaches the EOF well before it should, and
I know this also because the Filelen(ImportFile) function returns a smaller size than it shows after the app has run. It seems to me that because I am opening up the text file immediately after Shellexecute ,it has somehow not been fully created and saved.
Help...

Your program won't be able to load the file as it's being written, because only one program can open the file at a time. In this case, VB would give an error that the file was already open. Your problem may be to do with translation of \r\n characters. (The most annoying problem in the Windows world)

files opened with the INPUT keyword can be opened more than once simultaneously by the same program or by separate ones.

fyi

Try this:

Code:

---

On Error Resume Next
Do
    Err.Clear
    Open ImportFile For Binary Access Write As #iFileNum
    Close #FileNum
Loop While Err

Open ImportFile For Input As #iFileNum
Do While Not EOF(iFileNum)
'...
'and the rest of your code
'...

---

This code assumes that you (or your program) has Write Permission to the file.

Good luck!

In your program are you doing something like the following sequence of events?

Note - this is pseudocode so don't take the following as being syntactically correct

Code:

---

Shellexecute arguments 'to run another exe that creates a text file

'then all the rest of your code

Open ImportFile For Input As #iFileNum
Do While Not EOF(iFileNum)
DoEvents ' allow user escape
Line Input #iFileNum, sLineRead

---

because if so, be aware that the shellexecute function call returns immediately with the process id of the executable running - it does not wait for the executable to finish before it returns control to your program.

So theres a pretty good chance that if you are doing something like the above "code" then the filehandling code may be executed before the file is even created if thats the way the operating system happens to schedule the processes running.

Hope this helps,

Mark

Hey guys,
I think funkyd77 probably has the correct reason, at least
that is how it is behaving. Any idea on how to prevent the next line in the code from executing before the ShellExecute function finishes it's work, ie, control should not be passed back to my app before the ShellExecute
finishes?

Well, if you look at my previous post you will see that I added a loop to try to open the file for Write access. This will not be possible until the program you have shelled has finished it job with it.

Good luck!

wossname - not if it's open for writing already.

rathtap, follow this link, I asked the same question once - how to wait until the other program finishes execution. The answer lies within - it uses the API.

http://forums.vb-world.net/showthread.php?threadid=6120

Hope this helps,

Mark

We are getting there guys. The answer was to use CreateProcess. But I have another teaser for you now:
"I am calling a DOS based app with CreateProcess.
It works great on my NT4.0 machine. But when I run it
on Win95/98,a blank MSDOS screen comes up and the program hangs. Task mgr says : "winoldap(not responding)".
So I guess my question is, what is different with how we use
CreateProcess between NT and 95/98?"

rathtap - did you try the sample code in that link? Because that worked for me <and some others i know>. I'm not too sure on the CreateProcess api call - that might be the cause of your problem between winNT and Win9x, <someone correct me if i'm wrong but...> the apis don't always behave the same across different windows platforms.

you might be better off using the shellexecute call because it is a vb builtin function and should give you greater consistency across the platforms. Which brings me back to the beginning - what made you change from shellexecute to the CreateProcess api call?

cheers,

I used CreateProcess so that the control is not passed back to my app till the other app finishes its work. I used another API in the next line which is the one that prevents the return of control. I do not remember it right away since I am now home. I will reply with that in this post tomorrow.
Anyway, FunkyD, I will also try out the code in the link you suggested, and let you know how that does. Thanks for being around.

I continuation with my last post.
This is the code that first starts the process and
then waits for completeion before returning control.
'Start the program
If CreateProcess(vbNullString, App, sec1, sec2,False, pclass,0&, WorkDir, sinfo, pinfo) Then
'Wait
WaitForSingleObject pinfo.hProcess, INFINITE '
end if

This works great on NT but the CreateProcess hangs on
95 and 98.

Funkyd77,
I cannot use Shell since I need to pass parameters to the
app, therefore the code in the link you suggested will not work.

Rathtap,
Why can't you use the shell command? You can pass parameters to whatever program you want, even in DOS.

Code:

---


process = Shell("notepad " & "C:\myfile.txt", 3)

---

That works for me.

Anyway, if you know what your DOS window will say in the title caption, you can use the FINDWINDOW API.

Do a search on it and you can find info on it.

JazzBass

Added in Edit:

I found an example of the FINDWINDOW API
(This is done in VB 3. Find the right declaration for your version of VB

Code:

---

Declare Function Findwindow Lib "User" (ByVal lpClassName _
As Any, ByVal lpWindowName As Any) As Long

---

Procedure:

Code:

---

Do
    pWindow% = Findwindow(0&, "C:\winnt\system32\cmd.exe")
      If pWindow% <> 0 Then
          Exit Do
      End If
    DoEvents
Loop

---

That's it.

JazzBass :D

[Edited by JazzBass on 08-02-2000 at 09:43 AM]

If I use ShellExecute it works and generates the out.log:

lProcessID = ShellExecute(hwnd, "open", strPath _ & "\oce.exe", " -i Imtmp.txt -o out.log", strPath, SW_SHOW)

Same thing I try with shell, the DOS window flashes,but no
file is generated,even though it returns a valid ProcessID .

lProcessID = Shell(strPath & "\oce.exe -i Imtmp.txt -o _ out.log", vbNormalFocus)

Any other options?

Is there any significance in the fact that you have:

Code:

---

ShellExecute(hwnd, "open", strPath _ & "\oce.exe", " -i Imtmp.txt -o out.log", strPath, SW_SHOW)

'But then with shell

Shell(strPath & "\oce.exe -i Imtmp.txt -o _ out.log", vbNormalFocus)

---

ie in the Shell call you have an underscore in your "parameters".

Because coincidentally what i'm working on today uses the Shell function to pass parameters to another program:

Code:

---

Shell App.Path & "\calledexe.exe " & strParms, vbNormalFocus

---

and this appears to work fine - ie the parameters are put to the command line and passed to the called exe.

so apart from the abovementioned difference in your parameters i can't think of anything else at the moment.

I added the underscore in this post to make it
readable, guess it only served to confuse more.
The parameters are the same in both instances.
Because the CreateProcess and WaitForSingleObject
combination works like a dream with NT, by starting the
DOS based app and not returning control to the calling
app till the DOS app terminates, it really
would be great for me to be able to find why it does
not work on 95 and 98 platforms.