nick at lurcher.org
Sun Jan 18 10:17:00 GMT 2009
Peter Harvey wrote:
>Nick Gorham wrote:
>>Peter Harvey wrote:
>>>Yes; I agree that your solution does work but would it be slightly
>>>(with no real down-side) to pass in an ODBCINSTWND? Advantages (however
>>>- 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
>>>IF ( WIN )
>>> - ignore hwnd OR
>>> - assume HWND is MS window handle
>>> - ignore hwnd OR
>>> - assume HWND is ref to an ODBCINSTWND
>>But where is the parent handle going to come from, normally its
>>directly from the app, we just added a specific case where the app
>>doesn't select a DSN, but thats going to (IMHO) be very rare.
>>Whatever we may like to think about unixODBC, there are three non
>>windows driver managers, and a driver writer will write what works for
>>at least two of them, probably all three.
>>I dont see app writers changing anything, most already have their own
>>dialog or menu to select a DSN. And I dont know of any drivers that do
>>what you suggest. The last thing a driver writer wants to do is tie
>>the driver to a lib that will make it hard to build one binary lib
>>that works on many platforms.
>I agree that this is all about edge cases but we are not talking about
>any significant (coding) work to pass the window handle down to the driver.
I just had to go and check, but as I thought, the driver manager already
passes the handle down to the driver. The hwnd that is passed into
SQLDriverConnect, is passed into SQLDriverConnect in the driver (unless
I have missed somthing, which is entirly possible given its a Sunday
>1. Where does the window handle come from?
>An application can, if the developer wants, choose to pass a window
>handle as follows;
> hWnd = (SQLHWND)(this->winId());
> ODBCINSTWND Wnd;
> strcpy( Wnd.szUI, "odbcinstQ4" );
> Wnd.hWnd = this;
> hWnd = (SQLHWND)(&Wnd);
>This uses Qt as an example. I realize that the cases may be rare but in
>some ways its simply because app developers have not had a solution to this.
>2. Driver developer writing to least common denominator?
>Perhaps. In anycase I am just thinking that it is best to let the driver
>developer decide since its so little effort to just provide the window
>3. " tie the driver to a lib that will make it hard to build one binary
>lib that works on many platforms"
>A driver developer could carry on ignoring the window handle (no
>effort), or use it knowing the type (on UNIX'sm) is ODBCINSTWND.
>I think this is a pretty good case for passing the window handle to the
>driver - but perhaps there is existing usage that you are concerned
>about... that passing in the window handle will cause existing drivers
>to fail? I doubt I can add much more in the way to make my case so I
>will step back and let you decided. In the end "its all good to me"... I
>have other things I can focus on :)
Well, as I said, we already are passing the handle, where I was unsure
as to the prtacticality of the thing, was attempting to assign any
meaning to the hwnd on non windows platforms. Its a catch 22 AFAIKS, the
app writers won't do it because there are no drivers that take notice
(so they have their own solution), the driver writers won't take notice
as no apps make use of it.
I guess as always I fall back on a rather lazy stance where open source
is at its best where the problem drives the solution, We added the extra
behaviour with no connection info being passed, as someone wanted it.
Of course if any app or driver writers out there are thinking "this is
just what I want" then please say so, and I will change my mind :-)
More information about the unixODBC-dev