Colin Jeanne

  • Content count

  • Joined

  • Last visited

Community Reputation

1114 Excellent

About Colin Jeanne

  • Rank
  1. GDI+

    I've written a small project with D2D and it is actually pretty easy to pick up and make things happen. I havent used GDI+ so I cant compare with respect to that but if you're making a game then D2D is certainly far easier than GDI.
  2. Small Unicode goofiness

    I've never seen this. Can you post a minimal example?
  3. Is FillRect() or CreateBrush() failing? You are leaking an HBRUSH by not storing and then deleting the brush created with CreateBrush() as well.
  4. You can always just draw the entire window yourself (that is, just make a WS_POPUP window without a title bar, etc. and then render the title bar as you see fit). Doing this will also require you to implement all of the title bar's functionality on your own. For other controls, many (such as button, listbox, etc.) can be created as owner-drawn, meaning, when it comes time to draw the control it will ask you how to draw it.
  5. win32 + drawing

    Dont load the bitmap in your game loop, load it when the program starts or at least load it when you need it and keep it until you dont. Right now you are just leaking HBITMAPs all over the place and GDI does not like leaked objects.
  6. Displaying Windows from the Taskbar

    I do not know where the formal documentation for the XML schema is although most of it is easy enough to guess. assemblyIdentity, for example, describes a single binary. The first one in the file describes your executable, what version it is, what architecture it runs on, etc. The dependentAssembly area describes a binary that your binary depends on. In that manifest it is describing comctl32 version (the one that came with XP). As for making data appear in the properties dialog of your application you will need a version resource. Finally, the reason you are getting Chinese is probably because the control is expecting a Unicode string but you are giving it an ANSI string.
  7. Windows 7 RC-1 install

    Why cant I install Windows on my USB drive?
  8. Displaying Windows from the Taskbar

    The basic idea is this: Many DLLs, such as comctl32.dll are used by a large number of programs. Since backwards compatibility must be maintained making changes to the controls in comctl32 is dangerous due to the high potential of breaking applications that have already been written and deployed. In XP, however, a large change to comctl32 was necessary in order to create the new theme API - this change broke a whole lot of apps. If you can only have one version of comctl32 on the system then you have two options 1) break a whole lot of apps and ensure that your customers never upgrade to XP or 2) ditch the new theme API and ensure that XP looks the same as 2000 making most people not want to upgrade to XP (since it is the same on the surface). Both situations mean XP wont sell. Solution? Find a way to run multiple versions of comctl32 at the same time! The default must be the pre-XP comctl32 (version 5.2) since old apps dont know how to request it which means that new programs will need to request the new version in order to use it. This is where manifests come in. Manifests are the way to go since you need to know which version of comctl32 to load before the program starts running (switching versions at runtime would be mind-numbingly dangerous) and so you need a way of embedding the data within the binary that is not in the code.
  9. Language packs

    The basic idea is that, rather than string literals, you use identifiers in your program which correspond to the various strings. To switch language you switch what strings those identifiers correspond to. How you set up the mapping is up to you and your requirements.
  10. Windows Stations and Desktops in General

    Task Manager is part of the OS. It can do things that normal programs can not do. As for communicating between desktops - the key here is to not use real desktops. The key is to simulate that there are different desktops since otherwise you run into all sorts of possibly intractable issues.
  11. Windows Stations and Desktops in General

    Quote:Original post by VirtualProgrammer Hmm, so am I right in assuming that the "Default" desktop does not have the DESKTOP_ENUMERATE right? I'm no expert at desktops so I dont know. It might also be that perhaps those desktops do not allow themselves to be enumerated. Quote:Original post by VirtualProgrammer EDIT - I just remembered that I created another desktop just for testing purposes, then while in the new desktop I pressed CTRL+ALT+DELETE and got the task manager, I could see the programs running from the other "Default" desktop but not on the active desktop (the one I created), why is this? is it to do with the Windows Station or something? If I understand what you did and if I understand what the task manager reports, I do not believe the task manager reports any application besides those running on the current desktop. Quote:Original post by VirtualProgrammer Hmm I see, so if a desktop named "TempDesktop" already exists and I try to create another desktop with the same name I get the handle to a already existing desktop? OK that makes sense, but wouldn't that give the same as result OpenDesktop()? Most Open*() functions in the Win32 API only differ from the Create*() functions in that the Open*() functions fail if the object does not already exist.
  12. Windows Stations and Desktops in General

    It sounds like your application does not have the rights to enumerate those desktops. Having said that, if you want a virtual desktop manager using actual Windows desktops is going to be a bad move. Switching between desktop objects is very expensive: for example, you know that long wait when UAC is activated on Vista? That wait is mainly from the switch to the secure desktop. Instead you probably just want to make clever use of ShowWindow() with SW_HIDE. If you remember XP's virtual desktop manager powertoy, this is what it used.
  13. CoUnitialize

    This is also the wrong way to use CoInitialize() and CoUninitialize() - call them at the beginning and end of your thread (or program if you have only one thread), respectively. Do not call them at the beginning and ending of each function which uses COM since CoUninitialize() will destroy all outstanding interfaces.
  14. wm_keydown, or GetAsyncKeyState?

    WM_KEYDOWN will also give you the virtual key code, of which there are VK_LSHIFT and VK_RSHIFT. Whether you use WM_KEYDOWN or GetAsyncKeyState() depends on the structure of your game. If you are doing processing for you game's state in your window procedure then WM_KEYDOWN is probably a good bet.
  15. Help with GDI back buffering

    To start: Do not call InvalidateRect() from WM_PAINT. Ever. InvalidateRect() will cause WM_PAINT to be placed in your message queue again, resulting in an endless loop of probably useless paints. Do not use GetDC()/ReleaseDC() in WM_PAINT to acquire the DC you are drawing to. These will not clear the dirty rect for the DC. Use BeginPaint() and EndPaint().