I can see multiple possible re-writes for this. It all depends on what is supposed to be in Recipient List at any given time.

1. Open file, loop through 1 to li_count, keep adding to file, run after loop

for li_loops = 1 to li_count
   if li_loops = 1 then
      li_FileNum = FileOpen("Recipient List.txt", TextMode!, Write!, Shared!, Append!)
   end if
   //populate ls_email_list variable from database view
   FileWriteEx(li_FileNum, ls_email_list)
   if li_loops = li_count then
      if FileClose(li_FileNum) = 1 then
         Run("notepad "+"Recipient List.txt")
      end if
   end if
next

2. Recipient list becomes multiple files which need creation/opening with every loop

string ls_Recipients
for li_loops = 1 to li_count
   ls_Recipients = "Recipient List_" + string(li_loops) + ".txt"
   li_FileNum = FileOpen(ls_Recipients, TextMode!, Write!, Shared!, Append!)
   //populate ls_email_list variable from database view
   FileWriteEx(li_FileNum, ls_email_list)
   if FileClose(li_FileNum) = 1 then
      Run("notepad " + ls_Recipients)
   end if
next

3. Recipient list stays single file, but gets opened, and waits for notepad to be closed with each loop

string ls_Recipients
ls_Recipients = "Recipient List.txt"
for li_loops = 1 to li_count
   li_FileNum = FileOpen(ls_Recipients, TextMode!, Write!, Shared!, Replace!)
   //populate ls_email_list variable from database view
   FileWriteEx(li_FileNum, ls_email_list)
   if FileClose(li_FileNum) = 1 then
      uo_RunAndWait.of_Run("notepad.exe " + ls_Recipients, uo_RunAndWait.SW_SHOWNORMAL)
   end if
next

Arnd pointed out what's causing the "file is still open" issue. If li_count > 1, then you're opening the file multiple times, but only closing (and releasing) it once. The remaining handles that were allocated stay live until your application is closed. A PB app running in the development environment is an extension of the PB dev environment. Nothing gets released until the Dev Env gets closed (with your app as written in your original post). The above three versions of your function solve that problem, and hopefully one of them should be what you originally needed for it to work right.

Thanks, Roland, I've found another way to skin the cat. I'm using a variable in the file name that increments, that way the same file is not re-used so there's no conflict.

The built in Run function and ShellExecute do not wait for the external program to finish. Calling it inside a loop will result in more than one app running at the same time.

The latest version of my RunAndWait example has a function ShellRunAndWait which might be what you need.

Great suggestions Chris, but still no luck. I created a separate executable and I used ShellExecuteW in both apps, but I'm still getting a file lock. I created an app called runfile that only does this:

string ls_Null
long ll_rc
SetNull(ls_Null)
ll_rc = ShellExecuteW ( handle( this ), "open", "notepad.exe", "Recipient List.txt", ls_Null, 1)
halt

Then my app that calls it does this:

string ls_Null
long ll_rc
SetNull(ls_Null)
ll_rc = ShellExecuteW ( handle( this ), "open", "runfile.exe", ls_Null, ls_Null, 1)

The operating system still thinks the file is being used by my app, even though the runfile app is what opens it.

This is your code:


for li_loops = 1 to li_count
   li_FileNum = FileOpen("Recipient List.txt", TextMode!, Write!, Shared!, Append!)
   //populate ls_email_list variable from database view
   FileWriteEx(li_FileNum, ls_email_list)
   if li_loops = li_count then
      if FileClose(li_FileNum) = 1 then
         Run("notepad "+"Recipient List.txt")
      end if
   end if
next

Please count how many times you do a FileOpen() and a FileClose() in the loop for li_count > 1.

hth

Arnd

Hi Kyle;

  Try using the ShellExecuteW API to run external processes. 

FYI: https://www.topwizprogramming.com/freecode_runandwait.html

 You could also breakdown that part of your app into a separate EXE to do the Run() command. That would alleviate the main App to continue processing until the Run there was completed, the EXE completes thus, freeing the file lock. Food for thought.

HTH

Regards ... Chris