Re: CommonDialog returns wrong context

Well, I tried setting the flag: it does not solve my problem. The dir
returned to my app is still the dir the user saves the print file in.
Probably because my app is calling the 'Print' CommonDialog (for which the
cdlOFNNoChangeDir flag is not listed BTW) and not the 'Open and Save As'
CommonDialog; it is the 'Print' CommonDialog which -thu some hidden magic-
decides to call the 'Open and Save As' CommonDialog without setting the
cdlOFNNoChangeDir flag to &H8.

So I am back at square one; the app has several Adodc controls which
initialize at form (re)-load (I assume that is what they do). Their
connectionstrings are pointing to a database in the current path. I can set
their properties at design time and I can change them in the Form load
procedure (e.g. assign the database path to a variable), but that's too late !

Should I really take all Adodc controls out and replace them with code ? Is
that my only option ? Couldn't I also set the connectionstrings to some dummy
database at design time using an absolute path (to satisfy the Adodc's while
initializing) and then in the form load procedure, change the
connectionstring to the App.Path ? This would mean 'only' one copy of the
database (could even be empty).

Thanks
nb0512

"nb0512" wrote:

Thanks Mike. I am aware that copying the database is really quick and DIRTY
if only because it will eventually lead to a hard disk with copies of the
database all over it as users choose different directories to save their
print files. But hey, I was kinda desparate.

On the 'probably best' solution, I fully agree and I am using a string
variable now. But parts of this app I wrote when I was still using Adodc
controls on my forms and I didn't -and stil don't- know how to get a string
var in it's connection string at design time ? Redefining the
connectionstring in the form load procedure does not help because of the Ado
pre-load events.

I will try the flag thing; it sounds good
Thanks
.
"MikeD" wrote:


"nb0512" <nb0512@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:C08FA153-1645-4D50-94E4-F3540657BDF9@xxxxxxxxxxxxxxxx
In my app I give the user the possibility to print a form using the
CommonDialog control. If no printer is attached, the MS Document Imager
automatically pops up. This also gives the user the option to save. If
user
does this, and selects the directory X to save the print in, the app
continues in this directory after the CommonDialog closes. On the form the
app returns to I have an Ado control which has a relative
connectionstring;
so the app now starts looking for the database in directory X -does not
find
it there of course- and crashes.
Since the Ado fires events even before the form loads, I cannot correct
this.

The workaround I implemented copies the database to the directory where
the
print was saved; (this to satisfy the Ado pre-load events) and then on the
form I reset the connectionstring to the correct value. This works OK, but
is
far from elegant.

Is there anyone who has encountered thsi same problem and is there a real
solution for it ? Thanks !!!



Copying the database as a means of solving this "problem" is probably one of
the worst ways (if not THE worst way) of "solving" it.

Before you show the dialog box, assign cdlOFNNoChangeDir to the Flags
property (you should OR this to any other flags you assign to this
property). This flag is actually intended for the Open and Save As dialogs,
but it *might* solve your problem as well.

Alternatively (and probably best), assign the database path to a variable
and always use that variable. It sounds like you're relying on the current
directory which is NOT good because as you've found out, the current
directory can change. If your database file is located in the same folder as
your application EXE file, you could also alternatively use App.Path.

--
Mike
Microsoft MVP Visual Basic


.

Relevant Pages

  • Re: Portable Database Choice
    ... I searched this group quite a bit looking for database alternatives and did find the options below from this search. ... I'm posting this in the hope it can be of use to other developers in a position similar to mine where I needed a low cost alternative to Pocket Access. ... One app requires synchronization between desktop and mobile device, the other requires a push of data from the desktop to mobile. ...
    (microsoft.public.dotnet.framework.compactframework)
  • Re: Portable Database Choice
    ... > database alternatives and did find the options below from this search. ... One app requires ... > push of data from the desktop to mobile. ... > Both of these apps used Pocket Access on the device with Peter Foot's ...
    (microsoft.public.dotnet.framework.compactframework)
  • Portable Database Choice
    ... database alternatives and did find the options below from this search. ... of data from the desktop to mobile. ... The read-only app requires speedy lookup of data in a flat table ... Both of these apps used Pocket Access on the device with Peter Foot's ...
    (microsoft.public.dotnet.framework.compactframework)
  • Re: Sqlserverce class not working when VB.Net application is running from network drive
    ... one app attempts to connect to a sdf file on a network share, ... possible that the database is already in use when you attempt to ...
    (microsoft.public.sqlserver.ce)
  • Re: MSVC++ app type choice, form design questions
    ... > 1) MSVC Project definition requires that for an MFC app I choose ... MFC's built-in database support is really built around the document/ ... with the full version of SQL Server, but it's still pretty usable -- ...
    (microsoft.public.vc.mfc)