Hi,
Is there a way to use the OutputX file capability like the tools menu uses for GWDscripts? Currently I use the Gte_GetTempFileName() for the output of an enhanced grep function. These files get saved in the recent files list which really clutters it up.

Thanks.

Yes:

HDOC hOutputDoc;


if((hOutputDoc = Gte_NewDocument()) != NULL)
{
Gte_ReadFile(hOutputDoc, szTempFileName);
Gte_SetFileName(hOutputDoc, "Compiler Output:");
Gte_SetModified(hOutputDoc, FALSE);
Gte_SetReadOnly(hOutputDoc, TRUE);
Gte_SetOutputWindow(hOutputDoc, TRUE);
Gte_SetActiveDocument(hOutputDoc);
}

where szTempFileName is the file name returned by Gte_GetTempFileName() function

Is there a way the next time, to find out if the file "Compiler Output:" is open and add to it?

You can sarch for it wih Gte_GetFirstDocument(), Gte_IsOutputWindow(hDoc); Gte_GetNextDocument(); functions. Here is the code from the Java compiler driver that do this

HDOC hDoc;
HDOC hOutputDoc;

// search for old capture file
hOutputDoc = NULL;
hDoc = Gte_GetFirstDocument();
if(hDoc)
{
   do
   {
      if(Gte_IsOutputWindow(hDoc))
      {
         hOutputDoc = hDoc;
         break;
      }
      hDoc = Gte_GetNextDocument(hDoc);
   }
   while(hDoc != NULL);
}
// if we didn't find old output window, create new one
if(hOutputDoc == NULL)
{
   if((hOutputDoc = Gte_NewDocument()) != NULL)
   {
      Gte_SetFileName(hOutputDoc, "Compiler Output:");
      Gte_SetModified(hOutputDoc, FALSE);
      Gte_SetReadOnly(hOutputDoc, TRUE);
      Gte_SetOutputWindow(hOutputDoc, TRUE);
   }
}

Oh, I didn't understand the Gte_IsOutputWindow() concept.
Thanks.

Another issue I have is that my grep routine writes the paths that it searches to stderr. This is captured at the end of the file when I do a Gte_ExecuteTool(cmdline, TempName, tmpstring, args);
Is there a way to redirect the stderr to "dev/null"?
I actually tried to change the grep routine to not write to stderr, but then it acted like the Gte_ExecuteTool() would miss some of the output (it would work ok from the command line though). Have you seen any of this behavior and are there any work-arounds?

It seems that the function Gte_ExecuteTool() does not always capture all of the output from a command. The alternative is to use the system() command. This is not a nice since it opens a dos window instead of the nice running tool window from Gte_ExecuteTool(). The WinExec() doesn't work either since it is non-blocking.

For capturing comman output Gte_ExecuteTool uses
gtecap32.exe program. GWD Text Editor starts this program
with following parameters:

gtecap32.exe capfile tool.exe [options..]

and this program then executes something like this:

tool.exe [options...] > capfile

You can try to replace gtecap32.exe with your implementation
and it should do exactly tool.exe [options...] > capfile
because AFIAK ">" does not capture stderr.

Here is the source code of the gtecap32.exe

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <process.h>

int main(int argc, char *argv[], char *env[])
{
   FILE *fpStdout, *fpStderr;
   int i;
   char *new_argv[256];

   if (argc < 3)
   {
      return 1;
   }

   fpStdout = freopen(argv[1], "w", stdout);
   fpStderr = freopen(argv[1], "w", stderr);

   new_argv[0] = argv[0];
   for (i = 3; i < argc; ++i) {
      new_argv[i-2] = argv[i];
   }
   new_argv[i-2] = NULL;
   spawnvp(P_WAIT, argv[2], new_argv);

   fclose(fpStdout);
   fclose(fpStderr);

   return 0;
}


Your implementation should look like this:


#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main(int argc, char *argv[], char *env[])
{
   char szCommandLine[512];
   int i;

   if (argc < 3)
      return 1;

   strcpy(szCommandLine, argv[2]);
   for(i = 3; i < argc; i++) {
      strcat(szCommandLine, " ");
      strcat(szCommandLine, argv[i]);
   }
   strcat(szCommandLine, " >");
   strcat(szCommandLine, argv[1]); // Redirect to file

   system(szCommandLine);

   return 0;
}