Jump to page: 1 2
Thread overview
Silent error when using hashmap
Jul 26, 2017
FatalCatharsis
Jul 26, 2017
ketmar
Jul 26, 2017
Mike Parker
Jul 27, 2017
FatalCatharsis
Jul 27, 2017
ketmar
Jul 27, 2017
FatalCatharsis
Jul 27, 2017
ketmar
Jul 27, 2017
FatalCatharsis
Jul 27, 2017
ketmar
Jul 27, 2017
FatalCatharsis
Jul 27, 2017
ketmar
Jul 27, 2017
FatalCatharsis
Jul 27, 2017
FoxyBrown
Jul 27, 2017
ketmar
Jul 27, 2017
Mike Parker
Jul 28, 2017
FatalCatharsis
July 26, 2017
I apologize, I'm not sure if this is expected behavior, a bug in the compiler, or a bug in the core windows libraries, so I'll post this here until pointed elsewhere.

I've done this trick with win32 for awhile in other languages where I pass a reference to a specific class of my own that represents an instance of window to the CreateWindowEx function, and then use a static router function to send messages to the specific instance. I've made the most minimal example I can in this gist.

https://gist.github.com/FatalCatharsis/d3cc6ec621f0600975806fe23610ae32

When I compile this and run this, nothing is printed and no window is created. I've tried putting try catches around everything (including the inside of the static constructor), but nothing is caught.

However, when I comment out the hash lookup on line 54, the compiled program runs fine and creates a window, (but only for a moment since there is not a message handling loop). The expected printout of "start" and "end" occurs just fine.

What is happening here that causes the program not execute at all, with no output and no exceptions? Is this a bug with my code, a bug with the core.sys.windows.windows library, or a bug with the compiler? Any info about how to debug this further is greatly appreciated.
July 26, 2017
FatalCatharsis wrote:

> I apologize, I'm not sure if this is expected behavior, a bug in the compiler, or a bug in the core windows libraries, so I'll post this here until pointed elsewhere.
>
> I've done this trick with win32 for awhile in other languages where I pass a reference to a specific class of my own that represents an instance of window to the CreateWindowEx function, and then use a static router function to send messages to the specific instance. I've made the most minimal example I can in this gist.
>
> https://gist.github.com/FatalCatharsis/d3cc6ec621f0600975806fe23610ae32
>
> When I compile this and run this, nothing is printed and no window is created. I've tried putting try catches around everything (including the inside of the static constructor), but nothing is caught.
>
> However, when I comment out the hash lookup on line 54, the compiled program runs fine and creates a window, (but only for a moment since there is not a message handling loop). The expected printout of "start" and "end" occurs just fine.
>
> What is happening here that causes the program not execute at all, with no output and no exceptions? Is this a bug with my code, a bug with the core.sys.windows.windows library, or a bug with the compiler? Any info about how to debug this further is greatly appreciated.

'cause `WM_CREATE` is not the first message window receiving. check if hwnd is in hash with `in` first.
July 26, 2017
On Wednesday, 26 July 2017 at 16:09:30 UTC, FatalCatharsis wrote:
> 
>
> When I compile this and run this, nothing is printed and no window is created. I've tried putting try catches around everything (including the inside of the static constructor), but nothing is caught.
>
You're casting this to void*, which is correct, but then when you fetch it back you're casting to a WinThing*, which is not correct. this is a reference, not a pointer. Cast to WinThing instead of WinThing*.
July 26, 2017
On 7/26/17 12:09 PM, FatalCatharsis wrote:
> I apologize, I'm not sure if this is expected behavior, a bug in the compiler, or a bug in the core windows libraries, so I'll post this here until pointed elsewhere.
> 
> I've done this trick with win32 for awhile in other languages where I pass a reference to a specific class of my own that represents an instance of window to the CreateWindowEx function, and then use a static router function to send messages to the specific instance. I've made the most minimal example I can in this gist.
> 
> https://gist.github.com/FatalCatharsis/d3cc6ec621f0600975806fe23610ae32
> 
> When I compile this and run this, nothing is printed and no window is created. I've tried putting try catches around everything (including the inside of the static constructor), but nothing is caught.

Note that in D when a thread crashes besides the main thread, you may not get a stack trace printout. You may get nothing.

-Steve
July 27, 2017
On Wednesday, 26 July 2017 at 16:39:15 UTC, ketmar wrote:>
> 'cause `WM_CREATE` is not the first message window receiving. check if hwnd is in hash with `in` first.

I figured this was the case. WM_NCCREATE is probably sent first and the lookup fails. I'm more concerned with why there was no exceptions/debug output of any kind.

On Wednesday, 26 July 2017 at 22:08:45 UTC, Steven Schveighoffer wrote:
> Note that in D when a thread crashes besides the main thread, you may not get a stack trace printout. You may get nothing.
>
> -Steve

This example doesn't create any threads explicitly. Are there other threads that dlang generates? How do I obtain debug output and proper exception handling from these threads?


July 27, 2017
FatalCatharsis wrote:

> On Wednesday, 26 July 2017 at 16:39:15 UTC, ketmar wrote:>
>> 'cause `WM_CREATE` is not the first message window receiving. check if hwnd is in hash with `in` first.
>
> I figured this was the case. WM_NCCREATE is probably sent first and the lookup fails. I'm more concerned with why there was no exceptions/debug output of any kind.

'cause windows' event handler called from darkes depths of windows code, and D just can't make sense of the stack to unwind it properly and to show you error message and stack trace. never ever rely on getting proper stack traces for exceptions thrown in windows callbacks: it *may* work sometimes, but it is not guaranteed.
July 27, 2017
On Thursday, 27 July 2017 at 00:12:20 UTC, ketmar wrote:
> 'cause windows' event handler called from darkes depths of windows code, and D just can't make sense of the stack to unwind it properly and to show you error message and stack trace. never ever rely on getting proper stack traces for exceptions thrown in windows callbacks: it *may* work sometimes, but it is not guaranteed.

Is there a way to get it to not fail so hard so that prints that occur before and after the failure aren't lost? The "begin" and "end" in the main don't even get output when the failure happens.


July 27, 2017
FatalCatharsis wrote:

> On Thursday, 27 July 2017 at 00:12:20 UTC, ketmar wrote:
>> 'cause windows' event handler called from darkes depths of windows code, and D just can't make sense of the stack to unwind it properly and to show you error message and stack trace. never ever rely on getting proper stack traces for exceptions thrown in windows callbacks: it *may* work sometimes, but it is not guaranteed.
>
> Is there a way to get it to not fail so hard so that prints that occur before and after the failure aren't lost? The "begin" and "end" in the main don't even get output when the failure happens.

wrap the whole event handler function in `try/catch` block, and print it there. after all, this is what Dmain does, and so can you. having *full* stack trace has no sense there anyway, as you know for sure that event handler is called by windows, not by you (and usually from your event loop anyway, so detailed stack trace has little useful info).
July 27, 2017
On Thursday, 27 July 2017 at 00:34:28 UTC, ketmar wrote:
> wrap the whole event handler function in `try/catch` block, and print it there. after all, this is what Dmain does, and so can you. having *full* stack trace has no sense there anyway, as you know for sure that event handler is called by windows, not by you (and usually from your event loop anyway, so detailed stack trace has little useful info).

I tried that like so:

https://gist.github.com/FatalCatharsis/39c5f35ae78ecd5399eebe0fb2491004

I put exception blocks both around main and around the invocation of the hash lookup and still get no printouts anywhere, including at the beginning and end of main.
July 27, 2017
FatalCatharsis wrote:

> On Thursday, 27 July 2017 at 00:34:28 UTC, ketmar wrote:
>> wrap the whole event handler function in `try/catch` block, and print it there. after all, this is what Dmain does, and so can you. having *full* stack trace has no sense there anyway, as you know for sure that event handler is called by windows, not by you (and usually from your event loop anyway, so detailed stack trace has little useful info).
>
> I tried that like so:
>
> https://gist.github.com/FatalCatharsis/39c5f35ae78ecd5399eebe0fb2491004
>
> I put exception blocks both around main and around the invocation of the hash lookup and still get no printouts anywhere, including at the beginning and end of main.

'cause you never printed anything.
« First   ‹ Prev
1 2