File Picker

[Jeremy DeHaan]

On Thursday, 12 December 2013 at 03:17:29 UTC, Malkierian wrote:
> On Tuesday, 10 December 2013 at 03:42:10 UTC, Malkierian wrote:
>> On Tuesday, 10 December 2013 at 02:05:12 UTC, Jeremy DeHaan 
>> wrote:
>>> On Monday, 9 December 2013 at 16:49:04 UTC, Malkierian wrote:
>>>> On Monday, 9 December 2013 at 08:57:16 UTC, Jeremy DeHaan 
>>>> wrote:
>>>>> On Monday, 9 December 2013 at 06:32:06 UTC, Malkierian 
>>>>> wrote:
>>>>>> *sigh* No dice.  And I can't get GtkD to work either, 
>>>>>> because of entry point errors...
>>>>>
>>>>> I've gotten GtkD to work for me, though it has been a 
>>>>> while. If I am able to find some time soon I will see if I 
>>>>> can do some kind of example for you.
>>>>
>>>> Well, in the mean time, have you ever heard of this error 
>>>> before?
>>>>
>>>> "The procedure entry point gdk_frame_clock_begin_updating 
>>>> could not be located in the dynamic link library 
>>>> libgdk-3-0.dll.
>>>>
>>>> I've also gotten a similar error with some other entry point 
>>>> in libgdk_pixbuf-2.0-0.dll, but then I copied that file from 
>>>> the Gtk 3.6.4 release into my bin folder and it went away.  
>>>> Copying the the libgdk-3-0.dll from the same release did 
>>>> nothing to fix this error.  This is getting ridiculous.
>>>
>>> I don't know if this is your problem exactly, but the Gtk+ 
>>> installer on the GtkD website(http://gtkd.org/download.html) 
>>> is for 3.8.1, so maybe something has been updated since then?
>>>
>>> You could also open an issue on GtkD's github 
>>> repo(https://github.com/gtkd-developers/GtkD) if you continue 
>>> to experience problems with it.
>>
>> LOL, that was the version I was replacing with the 3.6.4 stuff 
>> XD.  And I already made a post on their forum about it.
>
> So guess what?  I just recently was trying to troubleshoot 
> GtkD, and in the process I removed the bin folders for the 
> 64-bit versions of TortoiseGit and TortioseSVN from my PATH, 
> and when I switch back over to my other source set (the one 
> with the file chooser from here) suddenly the windows generic 
> chooser works fine.  I had to remove those two bin folders from 
> the path because, despite it being a 32-bit application, it was 
> apparently loading (or trying to load) a specific driver from 
> those folders that was messing everything up.
>
> So is this 32/64-bit crossover thing a bug in D, or is it just 
> a phantom random weird thing that was happening with my setup?

Mixing 32 bit code with 64 bit libraries, or vice versa, is (from 
what I have read) not usually a good thing and is not specific to 
the D language. If your program found a dll with the same name 
for one it is looking for I think it just goes for it. I have no 
idea if Windows can or does try to verify how many bits a library 
has before it loads it.