Re: File Picker

2013-12-12 Thread 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.


Re: File Picker

2013-12-09 Thread Jeremy DeHaan

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.


Re: File Picker

2013-12-09 Thread Malkierian

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.


Re: File Picker

2013-12-09 Thread Jeremy DeHaan

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.


Re: File Picker

2013-12-09 Thread Malkierian

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.


Re: File Picker

2013-12-08 Thread Marco Leise
Am Sun, 08 Dec 2013 05:49:34 +0100
schrieb Malkierian rhyd...@gmail.com:

 On Saturday, 7 December 2013 at 23:18:18 UTC, Adam D. Ruppe wrote:
  On Saturday, 7 December 2013 at 23:00:00 UTC, Malkierian wrote:
  Is there anything in D that currently brings up a window to 
  find and choose a file, or am I going to have to make it 
  myself?  Isn't there a built-in something or other I can hook 
  into in Windows?
 
  Yeah, on Windows, you can just call the GetOpenFileName 
  function (or GetSaveFileName if saving) and use the common 
  dialog.
  http://msdn.microsoft.com/en-us/library/windows/desktop/ms646927(v=vs.85).aspx
 
 
  I wrote this quick example to show how you can use it in D:
 
  http://arsdnet.net/dcode/open.d
 
 
  Since the windows headers distributed with dmd are woefully 
  incomplete, the first thing I did was copy/paste the struct and 
  file definition from MSDN.
 
  Then, below that, is the main() function which shows how to 
  call it. There's a lot of customization you can do there, see 
  the Microsoft docs for more info (or search the web for any C 
  examples, the function works the same way in D.)
 
 Man, that's great, thanks.  However, I have it set up in my 
 application, and when I first call it, I get this window:
 
 http://gyazo.com/02bc18bdc23fdf3c24aa4ff70b46be1f
 
 Then, if I cancel and open it again, I get the actual browser, 
 but then my program freezes up:
 
 http://gyazo.com/4e5e873e57cd7a234d56c7a42198ab89
 
 Any idea why it doesn't work the first time, but then does the 
 second and freezes?

Maybe it requires a working Windows® event loop in your
application, as is typical for GUI applications on any
platform. Windows typically generate all sorts of events, like
mouse clicks, key strokes, resize events etc. They add up in
the event queue and a white window like yours is typical of
Windows® to indicate that this application is no longer
working off its event loop. (Or in your case never started to
do so.)
If that is indeed the problem, worry not, because most events
can be handled by the default handler, but you'll need to
write an simple event loop. I'm not sure, but it could be that
you'll need to create a dummy window as well since event loops
work with window handles. Maybe it is ok to pass 0 everywhere,
maybe you need a valid handle.

-- 
Marco



Re: File Picker

2013-12-08 Thread Malkierian

On Sunday, 8 December 2013 at 09:17:37 UTC, Marco Leise wrote:


Maybe it requires a working Windows® event loop in your
application, as is typical for GUI applications on any
platform. Windows typically generate all sorts of events, like
mouse clicks, key strokes, resize events etc. They add up in
the event queue and a white window like yours is typical of
Windows® to indicate that this application is no longer
working off its event loop. (Or in your case never started to
do so.)
If that is indeed the problem, worry not, because most events
can be handled by the default handler, but you'll need to
write an simple event loop. I'm not sure, but it could be that
you'll need to create a dummy window as well since event loops
work with window handles. Maybe it is ok to pass 0 everywhere,
maybe you need a valid handle.


That's rather unfortunate, as I was using DSFML as my main event 
generator and handler.  I had a DSFML window up already that I 
was calling that function from.  I don't know how to make the 
crossover between the two in D.  I think I'll have to look into 
GtkD instead.  Thanks for the idea, though.


Re: File Picker

2013-12-08 Thread Adam D. Ruppe

On Sunday, 8 December 2013 at 04:49:35 UTC, Malkierian wrote:
Any idea why it doesn't work the first time, but then does the 
second and freezes?


Could be a missing argument to the function, I did a quick test 
on Windows XP and it looks like you're on Vista.


Later today, I'll be on my other Windows computer and I'll try it 
there and see what's going on.


Re: File Picker

2013-12-08 Thread Adam D. Ruppe
Hmm, I just tried from my Windows 7 computer and it worked.  If 
you do my sample program without changes


http://arsdnet.net/dcode/open.d

does it work, or is the problem after copy/pasting it into the 
rest of your program? Also are you compiling 64 bit? I only tried 
32 bit since my laptop has a 32 bit processor so that could be a 
problem too.


Re: File Picker

2013-12-08 Thread Malkierian

On Sunday, 8 December 2013 at 22:26:11 UTC, Adam D. Ruppe wrote:
Hmm, I just tried from my Windows 7 computer and it worked.  If 
you do my sample program without changes


http://arsdnet.net/dcode/open.d

does it work, or is the problem after copy/pasting it into the 
rest of your program? Also are you compiling 64 bit? I only 
tried 32 bit since my laptop has a 32 bit processor so that 
could be a problem too.


No, I'm not building in 64bit.  However, I just tried it, copy 
paste into my main, no additional libs or includes, only main.d 
compiling.  Still get a window like that first image, and if I 
put another one in after it, it does the same not responding 
issue.


Re: File Picker

2013-12-08 Thread Malkierian

On Sunday, 8 December 2013 at 23:17:46 UTC, Malkierian wrote:

On Sunday, 8 December 2013 at 22:26:11 UTC, Adam D. Ruppe wrote:
Hmm, I just tried from my Windows 7 computer and it worked.  
If you do my sample program without changes


http://arsdnet.net/dcode/open.d

does it work, or is the problem after copy/pasting it into the 
rest of your program? Also are you compiling 64 bit? I only 
tried 32 bit since my laptop has a 32 bit processor so that 
could be a problem too.


No, I'm not building in 64bit.  However, I just tried it, copy 
paste into my main, no additional libs or includes, only main.d 
compiling.  Still get a window like that first image, and if I 
put another one in after it, it does the same not responding 
issue.


I am working in Xamarin, though, if that makes a difference.


Re: File Picker

2013-12-08 Thread Jeremy DeHaan

On Sunday, 8 December 2013 at 23:32:54 UTC, Malkierian wrote:

On Sunday, 8 December 2013 at 23:17:46 UTC, Malkierian wrote:
On Sunday, 8 December 2013 at 22:26:11 UTC, Adam D. Ruppe 
wrote:
Hmm, I just tried from my Windows 7 computer and it worked.  
If you do my sample program without changes


http://arsdnet.net/dcode/open.d

does it work, or is the problem after copy/pasting it into 
the rest of your program? Also are you compiling 64 bit? I 
only tried 32 bit since my laptop has a 32 bit processor so 
that could be a problem too.


No, I'm not building in 64bit.  However, I just tried it, copy 
paste into my main, no additional libs or includes, only 
main.d compiling.  Still get a window like that first image, 
and if I put another one in after it, it does the same not 
responding issue.


I am working in Xamarin, though, if that makes a difference.


I just tested it myself building in Xamarin. Worked like it is 
supposed to, so I'm not sure what's up. I'm running Win7 though.


When I get home I can see if running this along side DSFML's 
event stuff is a problem, but I hope it isn't something specific 
to your computer. That would blow.


Re: File Picker

2013-12-08 Thread Adam D. Ruppe

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.


Re: File Picker

2013-12-08 Thread Malkierian

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.


Re: File Picker

2013-12-08 Thread Malkierian

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?


Re: File Picker

2013-12-08 Thread Jeremy DeHaan

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?


Re: File Picker

2013-12-08 Thread Malkierian

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...


File Picker

2013-12-07 Thread Malkierian
Is there anything in D that currently brings up a window to find 
and choose a file, or am I going to have to make it myself?  
Isn't there a built-in something or other I can hook into in 
Windows?


Re: File Picker

2013-12-07 Thread Adam D. Ruppe

On Saturday, 7 December 2013 at 23:00:00 UTC, Malkierian wrote:
Is there anything in D that currently brings up a window to 
find and choose a file, or am I going to have to make it 
myself?  Isn't there a built-in something or other I can hook 
into in Windows?


Yeah, on Windows, you can just call the GetOpenFileName function 
(or GetSaveFileName if saving) and use the common dialog.

http://msdn.microsoft.com/en-us/library/windows/desktop/ms646927(v=vs.85).aspx


I wrote this quick example to show how you can use it in D:

http://arsdnet.net/dcode/open.d


Since the windows headers distributed with dmd are woefully 
incomplete, the first thing I did was copy/paste the struct and 
file definition from MSDN.


Then, below that, is the main() function which shows how to call 
it. There's a lot of customization you can do there, see the 
Microsoft docs for more info (or search the web for any C 
examples, the function works the same way in D.)