I wonder if your other DSFML thingy use threads or something...

the GetOpenFileName function blocks until the user makes their choice. So that could be stalling the SFML event loop, or maybe having threading issues. I don't know. But I get the feeling that the problem is one of these two things.

On Monday, 9 December 2013 at 02:45:48 UTC, Adam D. Ruppe wrote:
> I wonder if your other DSFML thingy use threads or something...
>
> the GetOpenFileName function blocks until the user makes their choice. So that could be stalling the SFML event loop, or maybe having threading issues. I don't know. But I get the feeling that the problem is one of these two things.

Yes, but like I said, I took DSFML completely out of the project to do a test compile using only main.d and not linking any external libs (DSFML, GtkD, or DerelictAL). No special build instructions or anything in Xamarin, but the first time it's called, I get that first picture and the second time (after clicking cancel on the first one it's opened again in the code), it shows the proper file structure and freezes.  In my regular setup (not the main.d exclusive test), my program would continue to work just fine until I called the file chooser a second time.

On Monday, 9 December 2013 at 04:01:54 UTC, Malkierian wrote:
> On Monday, 9 December 2013 at 02:45:48 UTC, Adam D. Ruppe wrote:
>> I wonder if your other DSFML thingy use threads or something...
>>
>> the GetOpenFileName function blocks until the user makes their choice. So that could be stalling the SFML event loop, or maybe having threading issues. I don't know. But I get the feeling that the problem is one of these two things.
>
> Yes, but like I said, I took DSFML completely out of the project to do a test compile using only main.d and not linking any external libs (DSFML, GtkD, or DerelictAL). No special build instructions or anything in Xamarin, but the first time it's called, I get that first picture and the second time (after clicking cancel on the first one it's opened again in the code), it shows the proper file structure and freezes.  In my regular setup (not the main.d exclusive test), my program would continue to work just fine until I called the file chooser a second time.

What version(s) of dmd are you using?

On Monday, 9 December 2013 at 04:52:21 UTC, Malkierian wrote:
> On Monday, 9 December 2013 at 04:01:54 UTC, Malkierian wrote:
>> On Monday, 9 December 2013 at 02:45:48 UTC, Adam D. Ruppe wrote:
>>> I wonder if your other DSFML thingy use threads or something...
>>>
>>> the GetOpenFileName function blocks until the user makes their choice. So that could be stalling the SFML event loop, or maybe having threading issues. I don't know. But I get the feeling that the problem is one of these two things.
>>
>> Yes, but like I said, I took DSFML completely out of the project to do a test compile using only main.d and not linking any external libs (DSFML, GtkD, or DerelictAL). No special build instructions or anything in Xamarin, but the first time it's called, I get that first picture and the second time (after clicking cancel on the first one it's opened again in the code), it shows the proper file structure and freezes.  In my regular setup (not the main.d exclusive test), my program would continue to work just fine until I called the file chooser a second time.
>
> What version(s) of dmd are you using?

I used 2.064.2, and it worked for me. I know you recently upgraded though. Maybe you could try uninstalling and then reinstalling the compiler?

On Monday, 9 December 2013 at 05:09:42 UTC, Jeremy DeHaan wrote:
> On Monday, 9 December 2013 at 04:52:21 UTC, Malkierian wrote:
>> On Monday, 9 December 2013 at 04:01:54 UTC, Malkierian wrote:
>>> On Monday, 9 December 2013 at 02:45:48 UTC, Adam D. Ruppe wrote:
>>>> I wonder if your other DSFML thingy use threads or something...
>>>>
>>>> the GetOpenFileName function blocks until the user makes their choice. So that could be stalling the SFML event loop, or maybe having threading issues. I don't know. But I get the feeling that the problem is one of these two things.
>>>
>>> Yes, but like I said, I took DSFML completely out of the project to do a test compile using only main.d and not linking any external libs (DSFML, GtkD, or DerelictAL). No special build instructions or anything in Xamarin, but the first time it's called, I get that first picture and the second time (after clicking cancel on the first one it's opened again in the code), it shows the proper file structure and freezes.  In my regular setup (not the main.d exclusive test), my program would continue to work just fine until I called the file chooser a second time.
>>
>> What version(s) of dmd are you using?
>
> I used 2.064.2, and it worked for me. I know you recently upgraded though. Maybe you could try uninstalling and then reinstalling the compiler?

*sigh* No dice.  And I can't get GtkD to work either, because of entry point errors...

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.

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.

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.

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.

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?