16 ms·

Instead of laboriously calling CreateWindow() for every control, traditionally we would lay out a dialog resource in a .rc file (Visual Studio still has the dia

Instead of laboriously calling CreateWindow() for every control, traditionally we would lay out a dialog resource in a .rc file (Visual Studio still has the dialog editor to do it visually) and then use CreateDialog() instead of CreateWindow(). This will create all the controls for you. Add an application manifest and you can get modern UI styling and high-DPI support.

urbandw311er 1y ago
Great answer, helpful and not judgemental.
belter 1y ago
Look it up in Petzold they used to say...
userbinator 1y ago
You also get automatic tabbing between controls, and a few other keyboard shortcuts this way. Note that resizing them still needs to be done manually if you want that, but that's usually easy and not more than a few hundred bytes of code.
kazinator 1y ago
However, this approach is easily translatable to a language that has decent FFI, and requires nothing else: no resource compiler and linker to make a resource DLL. Resource files and their binary format are not a good API. If you have those CreateWindow calls in a decently high level language, you can probably meta-program some resource-like DSL that fits right in the language.
- int_19h 1y ago
  You don't need a "resource DLL"; the compiled .rc file gets linked directly into the binary, and any Win32 C toolchain is capable of doing that, including MinGW. As API goes, I don't see what's wrong with it (anymore so than Win32 in general). And you do get quite a lot for free, as GP mentioned. Hi-DPI, for example - .rc files use "dialog units" to measure all widgets, which, unlike raw pixel values you pass to CreateWindow, are DPI-independent.
  - kazinator 1y ago
    What if "the binary" is stock (not built or relinked by you) installation of a language run-time? That's more like the case I'm thinking of. A program like this nicely translates to that situation.
    - int_19h 1y ago
      I don't understand this scenario. If you're writing an .rc file, then by definition you are building your own app (or library, although having one that displays dialogs is rather unusual). Are you talking about localizable text, by chance?
      - kazinator 1y ago
        What if the app isn't in a language that links to an .exe, where we can include the .res file compiled from .rc? The language may have an .exe run-time, but we don't get to link that. In that case if we want to use a .rc file anyway, it seems we would want to create a resource DLL out of it and dynamically load it. (I'm aware that one reason for resource DLL's is for localizable strings. That use makes sense even of programs which can statically link the GUI layout resources.)
        int_19h 1y ago
        Ah, I see what you mean now. But the context is a Win32 app that is very deliberately written in C, so my take was from that perspective - i.e. there's no good reason to avoid .rc files and instead handwrite CreateWindow, handle DPI etc in this case. However, even in the case that you describe, you don't actually have to use a resource DLL. CreateDialogIndirect can be used to create a dialog from an array of DLGITEMTEMPLATE structs, each describing a single control. I'm not entirely sure, but I suspect that compiled dialogs are basically just a dump of that array (but if not you could always just create it manually).
pjmlp 1y ago
Only UNIX overlaps C standard library with OS library, and back in 1985 (Windows 1.0 release), there was still no standard to speak of. Sure there was K&R C, which each OS outside UNIX cherry picked what would be available. Additionally outside UNIX clones, the tradition among vendors has been that the C compiler is responsible for the standard library, not the platform. Thus the C library was provided by Borland, Watcom, Symantec, Microsoft, Green Hills, Zortech,.... Note it was the same on Mac OS, until MPW came to be. As it was in IBM and Unisys, micros and mainframes. VMS before OpenVMS. And so on. Since Windows 10, you have the Universal C Runtime as well.
- Narishma 1y ago
  I think you replied to the wrong comment.
tonyedgecombe 1y ago
>Visual Studio still has the dialog editor to do it visually They are using gcc.
- electroly 1y ago
  That doesn't matter; you can still use Visual Studio to create the .rc file. This technique still works great for MinGW-based projects. The important thing is that Visual Studio has a .rc dialog editor.
  - int_19h 1y ago
    There are several .rc editors for Windows outside of VS that incorporate visual dialog editing. Pelles C would be one example that still gets regular updates.
    - electroly 1y ago
      Thanks for the tip about Pelles C. I just fired it up and it's a little clunky (so is Visual Studio) but I was able to load and edit a .rc dialog resource. Visual Studio's old dialog editor is pretty crashy these days so it's great to have an alternative.

urbandw311er 1y ago

Great answer, helpful and not judgemental.

belter 1y ago

Look it up in Petzold they used to say...

userbinator 1y ago

You also get automatic tabbing between controls, and a few other keyboard shortcuts this way. Note that resizing them still needs to be done manually if you want that, but that's usually easy and not more than a few hundred bytes of code.

kazinator 1y ago

However, this approach is easily translatable to a language that has decent FFI, and requires nothing else: no resource compiler and linker to make a resource DLL. Resource files and their binary format are not a good API. If you have those CreateWindow calls in a decently high level language, you can probably meta-program some resource-like DSL that fits right in the language.

int_19h 1y ago
You don't need a "resource DLL"; the compiled .rc file gets linked directly into the binary, and any Win32 C toolchain is capable of doing that, including MinGW. As API goes, I don't see what's wrong with it (anymore so than Win32 in general). And you do get quite a lot for free, as GP mentioned. Hi-DPI, for example - .rc files use "dialog units" to measure all widgets, which, unlike raw pixel values you pass to CreateWindow, are DPI-independent.
- kazinator 1y ago
  What if "the binary" is stock (not built or relinked by you) installation of a language run-time? That's more like the case I'm thinking of. A program like this nicely translates to that situation.
  - int_19h 1y ago
    I don't understand this scenario. If you're writing an .rc file, then by definition you are building your own app (or library, although having one that displays dialogs is rather unusual). Are you talking about localizable text, by chance?
    - kazinator 1y ago
      What if the app isn't in a language that links to an .exe, where we can include the .res file compiled from .rc? The language may have an .exe run-time, but we don't get to link that. In that case if we want to use a .rc file anyway, it seems we would want to create a resource DLL out of it and dynamically load it. (I'm aware that one reason for resource DLL's is for localizable strings. That use makes sense even of programs which can statically link the GUI layout resources.)
      - int_19h 1y ago
        Ah, I see what you mean now. But the context is a Win32 app that is very deliberately written in C, so my take was from that perspective - i.e. there's no good reason to avoid .rc files and instead handwrite CreateWindow, handle DPI etc in this case. However, even in the case that you describe, you don't actually have to use a resource DLL. CreateDialogIndirect can be used to create a dialog from an array of DLGITEMTEMPLATE structs, each describing a single control. I'm not entirely sure, but I suspect that compiled dialogs are basically just a dump of that array (but if not you could always just create it manually).

pjmlp 1y ago

Only UNIX overlaps C standard library with OS library, and back in 1985 (Windows 1.0 release), there was still no standard to speak of. Sure there was K&R C, which each OS outside UNIX cherry picked what would be available. Additionally outside UNIX clones, the tradition among vendors has been that the C compiler is responsible for the standard library, not the platform. Thus the C library was provided by Borland, Watcom, Symantec, Microsoft, Green Hills, Zortech,.... Note it was the same on Mac OS, until MPW came to be. As it was in IBM and Unisys, micros and mainframes. VMS before OpenVMS. And so on. Since Windows 10, you have the Universal C Runtime as well.

Narishma 1y ago
I think you replied to the wrong comment.

tonyedgecombe 1y ago

>Visual Studio still has the dialog editor to do it visually They are using gcc.

electroly 1y ago
That doesn't matter; you can still use Visual Studio to create the .rc file. This technique still works great for MinGW-based projects. The important thing is that Visual Studio has a .rc dialog editor.
- int_19h 1y ago
  There are several .rc editors for Windows outside of VS that incorporate visual dialog editing. Pelles C would be one example that still gets regular updates.
  - electroly 1y ago
    Thanks for the tip about Pelles C. I just fired it up and it's a little clunky (so is Visual Studio) but I was able to load and edit a .rc dialog resource. Visual Studio's old dialog editor is pretty crashy these days so it's great to have an alternative.