How to skip delimters dialog in VisualC++ program?

J

Jacek

Hello,
I use Word 2000 and I call its mail merge from Visual C++. It is simply a DLL library, which calls directly the Word object which makes the mail merge, and I in my program call this DLL library.
I have header file and data source file as txt files, with delimiters "new line" between fields and "|" at the end of record. I have only one record in data source file.
It works, when I call Word before and fix the directories for header file and data source file from Word's menu "Mail merge" - then I fix also which delimiters should it use.
But when I call the function OpenDataSource in the DLL library (it means, that I want in the future to control the printing by choosing not always only one data source file, but just different ones):

mailMerge.OpenDataSource("d:\\datasource.txt", COleVariant((long) 4), vtFalse, vOpt, vOpt, vOpt, vOpt, vOpt, vOpt, vOpt, vOpt, vOpt, vOpt, vOpt);

then it doesn't work correctly, because it calls the default Word dialog which asks about the delimiters.
How can I skip this dialog? It is very important to skip it, since I want to make it fully automatic, without any user action. Is there for example a function which sets the delimiters (but without calling the dialog) before I call OpenDataSource?

Thank you in advance,
Jacek.
 
P

Peter Jamieson

As far as I know, there is no way to skip the delimiters dialog box. You
either have to use a method that does not display the box, or detect that
the dialog has occurred and respond to it. One way you could /try/ to avoid
this box is always to use ODBC to connect to your data, and always to have a
SCHEMA.INI that defines the delimiters for this particular file (in fact, if
you used this approach you might also need to define the columns in
SCHEMA.INI as well). However, that also requires that every user has ODBC
set up, that you maintain SCHEMA.INI programmatically, and so on.

If you do actually have some control over the delimiters, you could try
changing them - e.g. use tab for the field delimiter and CRLF for the record
delimiter, with no special end of file character. But you also have to
consider what you do with tabs in the data (quote the fields using "" and
double up double quotes in the data. It all gets more complicated than I
would like). When I have tried to avoid this kind of problem I've tried to
use rtf format (because .rtf is just a text file that can be produced
without using Word automation) with tab field delimiters, new paragraphs as
record delimiters, and consistent quoting to avoid "delimiters in the data"
problems. However, I don't actually have the conversion code you'd need. You
could also consider producing .mdb format directly using ADO and ADOX, then
using that as a data source, but you'd be limited to 255 columns I think.

--
Peter Jamieson

Jacek said:
Hello,
I use Word 2000 and I call its mail merge from Visual C++. It is simply a
DLL library, which calls directly the Word object which makes the mail
merge, and I in my program call this DLL library.
I have header file and data source file as txt files, with delimiters "new
line" between fields and "|" at the end of record. I have only one record in
data source file.
It works, when I call Word before and fix the directories for header file
and data source file from Word's menu "Mail merge" - then I fix also which
delimiters should it use.
But when I call the function OpenDataSource in the DLL library (it means,
that I want in the future to control the printing by choosing not always
only one data source file, but just different ones):
mailMerge.OpenDataSource("d:\\datasource.txt", COleVariant((long) 4),
vtFalse, vOpt, vOpt, vOpt, vOpt, vOpt, vOpt, vOpt, vOpt, vOpt, vOpt, vOpt);
then it doesn't work correctly, because it calls the default Word dialog
which asks about the delimiters.
How can I skip this dialog? It is very important to skip it, since I want
to make it fully automatic, without any user action. Is there for example a
function which sets the delimiters (but without calling the dialog) before I
call OpenDataSource?
 
J

Jacek

Hello Peter,
the dialog has occurred and respond to it. One way you could /try/ to avoid
this box is always to use ODBC to connect to your data, and always to have a
SCHEMA.INI that defines the delimiters for this particular file

I went this way and there has been created a file Schema.INI in the
directory, where lies my "datasource.txt". But I have a question about
setting "Format" in this Schema.INI file - how can I set the delimiters as
"newline" between fields and "|" (pipe sign) at the end of the record?
Because I have seen that the "Format" is just like:
Format=Delimited()
I assume that between "(" and ")" should I write the delimiters which I use,
shouldn't I? But how to write "newline" as delimiter? As "\n" or "CRLF" or
something else?

Best regards,
Jacek.

(in fact, if
 
P

Peter Jamieson

I hoped you might be able to choose not to use the pipe at the end - there's
no way to define that as "end of data" in the SCHEMA.INI.

As for the record delimiter, ODBC only ever recognises CRLF anyway. If
you're just using LF (i.e. the Unix approach) or CR it may not work. Which
is why there's no setting. Sorry, I should have mentioned that. But the main
thing is that you can specify the field delimiter - if you try setting up a
DSN using the ODBC administrator you'll see how SCHEMA.INI represents that.
Oh, but expect the DSN setup to give you worrying messages when you do
that - it always does here, then appears to work anyway.

--
Peter Jamieson

Jacek said:
Hello Peter,
the dialog has occurred and respond to it. One way you could /try/ to avoid
this box is always to use ODBC to connect to your data, and always to have a
SCHEMA.INI that defines the delimiters for this particular file

I went this way and there has been created a file Schema.INI in the
directory, where lies my "datasource.txt". But I have a question about
setting "Format" in this Schema.INI file - how can I set the delimiters as
"newline" between fields and "|" (pipe sign) at the end of the record?
Because I have seen that the "Format" is just like:
Format=Delimited()
I assume that between "(" and ")" should I write the delimiters which I use,
shouldn't I? But how to write "newline" as delimiter? As "\n" or "CRLF" or
something else?

Best regards,
Jacek.

(in fact, if
 
J

Jacek

Hi Peter,

At last it works, but I did something different. I had anyway some strange
problems with ODBC txt driver, so I changed the type of the header and data
source files from txt to html, and just created both files with following
format:
<HTML>
<BODY>
<TABLE>
<TR>
<TD>param1</TD><TD>param2</TD>........<TD>paramN</TD>
</TR>
</TABLE>
</BODY>
</HTML>

Param1, param2 and so on are the names of data fields which are replaced
with data in data source file.
After this the Word recognizes correctly that it must read the HTML files
and doesn't display any dialog window with questions about delimiters (since
it has already the delimiters as HTML tags). So now I can give dynamically
and totally automatic the header and data source file name to Word mail merge.

Best regards,
Jacek.



Peter Jamieson said:
I hoped you might be able to choose not to use the pipe at the end - there's
no way to define that as "end of data" in the SCHEMA.INI.

As for the record delimiter, ODBC only ever recognises CRLF anyway. If
you're just using LF (i.e. the Unix approach) or CR it may not work. Which
is why there's no setting. Sorry, I should have mentioned that. But the main
thing is that you can specify the field delimiter - if you try setting up a
DSN using the ODBC administrator you'll see how SCHEMA.INI represents that.
Oh, but expect the DSN setup to give you worrying messages when you do
that - it always does here, then appears to work anyway.
 
P

Peter Jamieson

Thanks for the feedback - just in case, as far as I know you'll be
restricted to around 63 columns using that approach.

--
Peter Jamieson

Jacek said:
Hi Peter,

At last it works, but I did something different. I had anyway some strange
problems with ODBC txt driver, so I changed the type of the header and data
source files from txt to html, and just created both files with following
format:
<HTML>
<BODY>
<TABLE>
<TR>
<TD>param1</TD><TD>param2</TD>........<TD>paramN</TD>
</TR>
</TABLE>
</BODY>
</HTML>

Param1, param2 and so on are the names of data fields which are replaced
with data in data source file.
After this the Word recognizes correctly that it must read the HTML files
and doesn't display any dialog window with questions about delimiters (since
it has already the delimiters as HTML tags). So now I can give dynamically
and totally automatic the header and data source file name to Word mail merge.

Best regards,
Jacek.
 
J

Jacek

Hello,
Yes, you're right, these 63 columns could be a problem..
So I have tried another solution: instead of html files using the mdb files,
but I have found a problem, namely when I open the header file in Word, it
doesn't recognize that it is mdb file and displays standard dialog for
delimiters. The data source file can be opened as mdb file.
Is this a bug or Word simply doesn't support mdb files as header?
Or maybe it will work from my program when I call "OpenHeaderSource"
function with name of mdb file?

Best regards,
Jacek.
 
P

Peter Jamieson

Word definitely does not support all combinations of file types if you are
using separate Header+Data, but I don't have a list of what works and what
does not work. Generally speaking I think Word asumes that if the data
source always comes complete with a header, it probably will not use
separate Data and Header sources.

Two points:
a. if you are creating a .mdb (presumably using ADO or some such) why do
you need a separate header?
b. just in case it affects you, with most OLE DB sources there is a limit
on the column count of around 255.
 
J

Jacek

a. if you are creating a .mdb (presumably using ADO or some such) why do
you need a separate header?

Oh I see, so I can simply read the data source mdb file and it will do also
the job for header.
b. just in case it affects you, with most OLE DB sources there is a limit
on the column count of around 255.

It's pretty enough for me - I use max. approx. 100 fields.

Thanks and best regards,
Jacek.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top