Re: unixODBC-CPP
"Peter Harvey" <[email protected]>
| Newsgroups | gmane.comp.db.unixodbc.devel |
|---|---|
| Message-ID | <000101c978f3$d4160a10$7c421e30$@org> |
> -----Original Message----- > From: [email protected] [mailto:unixodbc-dev- > [email protected]] 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 _______________________________________________ unixODBC-dev mailing list [email protected] http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev