Date:         Thu, 2 Jan 1997 07:38:02 GMT
Reply-To:     Clark Roberts <dacmr@MINDSPRING.COM>
Sender:       "SAS(r) Discussion" <SAS-L@UGA.CC.UGA.EDU>
From:         Clark Roberts <dacmr@MINDSPRING.COM>
Organization: Decision Analytics
Subject:      Re: DDE
Content-Type: text/plain; charset=us-ascii

I stand corrected on my earlier comment (posted earlier this morning) about the
filename syntax
possibly being incorrect, and only being able to communicate with a document
through bookmarks.  I
was able to get your example to work by setting the noxwait and noxsync
options, which you must have
set as defaults.  I also tried shortening the example by having Word open the
tim.doc file on
invocation.  This also worked under SAS 6.12 in WFWG 3.11 as shown by the
following log:
 
______________________________________________________________________
357   options noxwait noxsync;
358
359   x 'c:\msoffice\winword\winword c:\tim.doc'
359                                             ;
360
361   filename tim dde 'winword|c:\tim.doc' command;
362
363   data _null_;
364      file tim;
365      x=sleep(5);
366      put '[Insert "%%%%%%%%%%%%%%%%%%%%%%%%%%"]';
367      put '[FilePrint]';
368      put '[FileSave]';
369      put '[FileExit 2]';
370      stop;
371   run;
 
NOTE: The file TIM is:
      FILENAME=winword|c:\tim.doc,
      RECFM=V,LRECL=256
 
NOTE: 4 records were written to the file TIM.
      The minimum record length was 10.
      The maximum record length was 37.
NOTE: The DATA statement used 7.29 seconds.
_______________________________________________________
 
The above also worked in this environment without the sleep function, but the
Word installation on
this machine opens very quickly.  I've been working on another system with SAS
6.11 under Win95 and
have had problems similar to yours because of network traffic slowing the Word
startup process.  I
was receiving the same '....... file not found,' etc. messages as you.
Inserting the sleep function
gave Word enough time to open and the problems stopped.  This may be what's
causing one of your
intermittent problem?  The other problem, that certain data  opens the Word
menus, is another story.
Without an example to actually test I couldn't help you.  If you'd post, or
e-mail me,  an example
that isn't working I'd be glad to take a look at it.
 
Although the use of bookmarks has been the best approach for  the work I've
been doing lately,
populating Word tables,  the 'filename - command' syntax will come in handy in
the future, so thanks
for the enlightenment.
 
Clark
__________________________________________________
 
On 1 Jan 1997 01:12:24 GMT, lpogoda@aol.com wrote:
 
 
>
>Thanks to all those who've responded to my plea for help so far.  However,
>the responses lead me to think my original statment of the problem was
>less than clear.  I'm in the office today, so let me repost the problem
>with an actual example instead of attempting to do so from memory.
>
>The task at hand is to write a series of final reports to Microsoft Word.
>I've tried a couple of approaches:
>
>1.  Write the reports to a flat file.  Import the flat file to Word.
>2.  Write the reports directly to Word.
>
>In the first case, the statements required to import a file can be
>determined by recording a word macro that imports a file and using the
>resulting WordBasic statements as a guide.
>
>In the second case, the report stream includes characters Word apparently
>recoginizes as keystrokes rather than data - for instance, a percent sign
>(%) activates the menu bar, halting further output until the menu bar is
>manually closed.  The report stream is therefore recast as a series of
>WordBasic statements.
>
>In both cases, output is being sent to the "command" level of Word, not
>directly to the body of the Word document.
>
>The sample log that follows is taken from a run under Win95.  When run
>under Win 3.11, both data steps shown *always* succeed.  Under Win95, the
>first data step fails most of the time, the second usually, but not
>always, succeeds.  If the first is omitted, the second usually fails.
>Once one attempt succeeds, all subsequent attempts also succeed.  I've not
>yet had a third attempt succeed when the first two fail.
>
>In all cases, document1 always exists - I can see it on the screen - and
>document TIM is a file I can see using file manager or explorer.
>
>Any help would be greatly appreciated.
>
>A sample log:
>
>73         x 'winword'
>73                    ;
>74         filename doc1 dde 'winword|document1' command;
>75         filename TIM dde 'winword|TIM' command;
>76         data _null_;
>77            file doc1;
>78            put '[Insert "This is a dummy string."]';
>79            put '[EditSelectAll]';
>80            put '[EditClear]';
>81            stop;
>82         run;
>
>ERROR: Physical file does not exist, winword|document1.
>NOTE: The SAS System stopped processing this step because of errors.
>NOTE: The DATA statement used 1.42 seconds.
>
>
>83         data _null_;
>84            file doc1;
>85            put '[ChDefaultDir "\\STATSPXL02\DATA07\INCPREV\WORKFILE\",
>0]';
>86            put '[FileOpen .Name = "TIM.DOC"]';
>87            stop;
>88         run;
>
>ERROR: Physical file does not exist, winword|document1.
>NOTE: The SAS System stopped processing this step because of errors.
>NOTE: The DATA statement used 6.58 seconds.
>
>
>
 
Clark Roberts
Decision Analytics, A SAS Institute Quality Partner(tm)
e-Mail dacmr@mindspring.com  or
       Clark_Roberts@depotech.com
Voice/Message/Fax: (619) 565-9627
Pager:             (619) 975-0758
_____________________________________________
 
SAS and SAS Institute Quality Partner are
registered trademarks or trademarks of SAS
Institute Inc. in the USA and other countries.
______________________________________________