[unixODBC-dev] unixODBC-CPP

Peter Harvey pharvey at peterharvey.org
Sat Jan 17 22:34:57 GMT 2009



> -----Original Message-----
> From: unixodbc-dev-bounces at mailman.unixodbc.org [mailto:unixodbc-dev-
> bounces at mailman.unixodbc.org] On Behalf Of Nick Gorham
> Sent: Saturday, January 17, 2009 9:42 AM
> To: Development issues and topics for unixODBC
> Subject: Re: [unixODBC-dev] unixODBC-CPP
> 
> Peter Harvey wrote:
> 
> >>Just hack the code in DriverManager/SQLDriverConnect.c to null the
> >>handle before calling the driver, what we have done here doesn't need
> >>any more (or less) code in the driver to deal with prompts, that bit
> >>is entirly up to the driver.
> >>
> >>I don't think we can ever assume that apps are going to pass a valid
> >>handle into the call though. (with reference to your other email to
> >>the sqllite chap).
> >>
> >>
> >>
> >
> >
> >Well the driver is going to have to do something platform specific to
> >fully handle SQLDriverConnect. I suppose one approach would be to
> always
> >pass a NULL window handle to the driver but that would either result
> in
> >an IM008 at times or the driver would have to do something platform
> >specific to prompt. My thinking is pass the ODBCINSTWND to the driver
> >and let the platform specific approach have a bit more information to
> >work with.
> >
> >--
> >Peter
> >
> >
> >
> Well, what I have done in the past with Easysoft drivers (though we
> don't bother now as no app ever makes use of it) is to ignore the
> window
> handle and just try and bring a Qt session up, no need for any special
> information from anywhere, My point is how would a application create a
> ODBCINSTWND even if it wanted to?
> 
> Given that Qt is going to be released under the LGPL now there is even
> less reason why a driver writer could not do the same as we did. It
> needs no platform specific code at all, just creating a QApplicaion and
> passing control to it. In just the same way as the odbcinstQ code does.
> 

Yes; I agree that your solution does work but would it be slightly better
(with no real down-side) to pass in an ODBCINSTWND? Advantages (however
slight) are;

- greater chance of the dialog being properly parented
- greater chance that the dialog will look & feel the same as the parent

The driver can then decide to use the approach the developer feels is best;
 
IF ( WIN )
   - ignore hwnd OR
   - assume HWND is MS window handle
ELSE
   - ignore hwnd OR
   - assume HWND is ref to an ODBCINSTWND

--
Peter




More information about the unixODBC-dev mailing list