gamedevlists-windows

Re:[GD-Windows] Windows in .NET :(

[Joe C. <jo...@mu...>]

  Hmm...

Well adding an empty wndproc wasn't enough. I had to set the cursor and 
icon as well. Looks like
it still complains about an invalid menu handler but it doesn't crash 
anymore :)

The window is only used to get the wgl extensions.  Basically create a 
fake window,
get the wgl extensions and then destroy the window. I guess .NET is a 
bit pickier than
vc6 libs.

As far as .NET being horribly broken... well one could argue that the 
change from workspaces
to solutions is broken. It definately does not behave the same as vc6 
workspaces. ;)

Thanks,

-Joe

Javier Arevalo wrote:

Brian Sharon <bs...@mi...> wrote:

>(cc'ing the Windows list and removing the general list)
>
>You haven't specified a WNDPROC for your window class.  That might be
>one lame reason.
>

That would definitely hurt a lot. :)

In case oyu wonder if .NET is horribly broken or something, we compiled the
full Praetorians source code in both managed and non-managed modes with
VS.NET. We had to make five or six syntax changes, we were hit by one code
generation bug regarding float constants, and we were appalled by the
trouble that managed C++ has with virtual function calls (fixed in the next
version I believe). Other than that, the entire game ran just fine.

>>-----Original Message-----
>>From: Joe Collins [mailto:jo...@mu...]
>>

>>On a side note, I have previously tried to get the mousewheel
>>working in my code. But
>>I get a compile error when I try to use WM_MOUSEWHEEL - undefined
>>
>>There seems to be some magic defines you need to set to get this to
>>compile... Something to do with
>>#define _WIN32_WINNT 0x0400
>>#define _WIN32_WINDOWS 0x500
>>

The mousewheel was not available in windows 95, therefore if you want to use
it you must specify that you won't be supporting Win98. All this is
explained in the MSDN help entry for WM_MOUSEWHEEL. We simply defined them
ourselves to avoid messing with equally obscure include-control macros:

#ifndef WM_MOUSEWHEEL
#define WM_MOUSEWHEEL 0x020A
#endif

#ifndef MSH_MOUSEWHEEL
#define MSH_MOUSEWHEEL 0xC7B1
#endif

  Javier Arevalo
  Pyro Studios

Re: Re:[GD-Windows] Windows in .NET :(

[Javier A. <ja...@py...>]

Joe Collins <jo...@mu...> wrote:

> Well adding an empty wndproc wasn't enough. I had to set the cursor
> and icon as well. Looks like
> it still complains about an invalid menu handler but it doesn't crash
> anymore :)

Clearing all fields to zero is definitely a good idea. You don't want to
have a random window proc, a random icon handle or such stuff in your window
class.

For a dummy window, ::DefWindowProc() as the window proc should be good
enough, but quite frankly, I have never done that myself (even for the
dumbest of hello world apps I at least add a check for ESC). I have no clue
if a NULL WndProc is supposed to work.

> I guess .NET is a bit pickier than vc6 libs.

Uninitialized variables are always broken no matter the compiler. It's just
that sometimes they happen to not blow up in your face. :)

> As far as .NET being horribly broken... well one could argue that the
> change from workspaces
> to solutions is broken. It definately does not behave the same as vc6
> workspaces. ;)

I don't particularly care about solutions vs. workspaces, but I definitely
agree that many tasks in the new IDE are much more cumbersome than in VC6:

 - They require more mouse clicks for just about everything,
 - Some hotkeys like Alt-F7 are now context-dependent,
 - The advanced editor mode has a tendency to start eating your source code
away.

If you're doing non-.NET C++ projects then it's definitely a good idea to
stick with VC6 (that's what I do) and wait for future, more refined versions
of the new environment. But it doesn't hurt to play with it on the side
(.NET forms are _cool_, MFC be gone for good!) to minimize the future
transition.

  Javier Arevalo
  Pyro Studios