[unixODBC-dev] unixODBC-CPP

Peter Harvey pharvey at peterharvey.org
Sun Jan 18 02:32:10 GMT 2009

Nick Gorham wrote:
> Peter Harvey wrote:
>> 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
>>   - ignore hwnd OR
>>   - assume HWND is ref to an ODBCINSTWND
>> -- 
>> Peter
> 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.
> Again IMHO.

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.

1. Where does the window handle come from?

An application can, if the developer wants, choose to pass a window
handle as follows;

#ifdef WIN
    hWnd = (SQLHWND)(this->winId());

    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 :)


More information about the unixODBC-dev mailing list