LE_HIDE does not help to hide cmd window

[hfvikingarna]

Hi,

I have built a GUI appllication by LabWindows/CVI, which launches another console application, say console_appl.exe bult by LabWindows/CVI too. The code is like

    LaunchExecutableEx("cmd /C console_appl.exe > temp.txt", LE_HIDE, &handle);

The problem is that the CMD windows can not be hidden. However, if the executable is not the console application built by LabWindows/CVI (say built-in command dir), the CMD windowsis indeed hidden. I appreciate if somebody can help me to solve this problem.

Hong

[jose.olvera@optichron.com]

1.- years ago I did some code to read/write into/from a binary file ..typical float values

and I just tried to re-use it now on LabWindows Rev 9.0. and I am having problems

2.-  when debugging ....both functions I used ( frpint, fscanf) have two fields that may be 'new' (or different)

from the 'old' ones , this fields are : errno, and # characters written and look like this

num_of_char_written = fprintf (stream, %f, source);

num_of_char_written = fscanf (stream, %f, target);

3.-  the tp (or lib) (......ANSI C / INPUT/OUTPUT/ FORMATTED INPOUT-OUTPUT )

 does not have the other field mentioned above : ERRNO  ..... ????

Could you confirm if this is an error ?   if not , could you explain why is not used ?  any easy (brief or simple)  example

for these two functions ?

Again, my code use to work OK on a very old REV (before REV5.0) ...meanwhile I may try it using REV 05

regards

Jose Olvera

[dummy_decoy]

(it would be nice if you posted new questions into their own thread, instead of reusing an old thread...)

fprintf() and fscanf() have not changed at all since years, also, the errno variable is defined since the beginning of the language. the standard C library defines a global variable called "errno". when you call a function from the library and something goes wrong,  the standard library sets an error code into this variable. generally, functions which return zero on error sets a detailed error code into errno.

the "# of characters written" is not a "field": in standard software development terms, it is called the return value of the function...

anyway, since these functions have not changed, you should not have any problem compiling your code with version 9.0 of CVI. what kind of error message do you get ?

[jose.olvera@optichron.com]

OK  ....let me explain

1.- my code fails for both Bianry (or ascii) files

2.- I changed it to use 'ARRAYs' and 'structs'  (rather than individual variables) ..... and both trials worked OK 

3.- the basic problem .... I cannot read back the values I suppose to be writing into the file (binary or ascii) ...both trial failed

 the code is next

=====   binary write  code         

   
 pFile = fopen (filename, "ab");   /* create - append the file */ 
       
        fprintf(pFile,"%f ,%f ,%f ,%f \n",
         val1,
         val2,
         val3,
         val4);

       
        fprintf( pFile, "%f , %f ,  %f , %f \n",
         val5,
         val6,
         val7,
         val8);
           
        fprintf( pFile, "%f , %f , %f , %f \n",
        val9,
        val10,
        val11,
        val12);
           
   fclose( pFile );

===  binary read code

 if ( ( pFile = fopen( filename, "rb" ) ) == NULL )
   {
      printf(" open file error");
   }

   while ( ! feof( pFile ) )    /* read till end of file is reached */
   {
       fscanf(  pFile, "%f , %f , %f , %f \n",
          &val1,
         &val2,
         &val3,
         &val4);

        printf("\n the G1 values %f   %f   %f   %f ", val1, val2,val3,val4);

         
          fscanf(  pFile, "%f, %f, %f, %f \n",
          &val5,
         &val6,
         &val7,
         &val8);

        printf("\n the G2 values  %f   %f   %f   %f", val5, val6,val7,val8);
       
          fscanf(  pFile, "%f, %f, %f, %f \n",
          &val9,
         &val10,
         &val11,
         &val12);

        printf("\n the G3 values  %f   %f   %f   %f", val9, val10,val11,val12);     
   
   }


   fclose( pFile );

[dummy_decoy]

the only problem i met with your code is data formatting: when writing your value, you put spaces before and after each coma in fprintf(), but when reading you only put a space after the coma in fscanf(). thus fscanf() fails when reading back the data, the file pointer is not moved to the end of the line, breaking all following reads, the end of file is never reached and the program loops forever.

to catch this error, you can test the return value of each fscanf, which should return 4 in your case: 4 items (%f) are read from the file and stored into their respective variable.the errno variable may also report an error (here it did not) but i find its use not clearly defined and rather system dependent, this hurts portability.

note that opening a file with a binary flag set, does not make the file binary, it only prevents the standard library from making some character translations (likeconverting \n into \r\n on windows systems). writing a real binary file would involve calling fwrite:

fwrite( &val1, sizeof( val1 ), 1, pFile );

also,  i don't understand how this code could work when writing structures and arrays. you may post this code for a better understanding.

there is a last check i would make: i had no time to test this, but fprintf() and fscanf() may depend on the system locale settings to format floating point values. if your system is configured to use a dot ('.') as a decimal separator, fprintf() and fscanf() may break when fed with numbers using a coma (',') as a decimal separator.  since you are using a coma to separate each field, it may have strange effects. i had no time to test this, but check your system settings in the control panel, and see what happens when using '.' or ',' as a decimal separator.

[jose.olvera@optichron.com]

Thanks Champ .... the issue is closed

1.- After removing the commas, and making sure the 'spaces' were 'symmetrical' ..... it worked just fine

2.- When using Arrays or Struc .... of course... i did not used this same code 

NOTE: I did not used the 'fwrite' .... for now..... I just try to fix the original , and no more problems.

Regards

Jose