>> 101 ICON DISCARDABLE "sudoku.ico"
>> |_________________________________________________
>> |
>> icon((char *)LoadIcon(fl_display, MAKEINTRESOURCE(101)));
>
> Though I'm uneasy about just assuming the value is 101
> - in principle we could make it something else... (though likely never would!)
Right -- maintaining the 101 value as a macro definition in the .h file
is probably better than having that anonymous 101 magic number
appear twice in the .rc and .cxx file.
But the value itself, 101, has to be hardcoded /somewhere/, and I think
its value is quite arbitrary.. probably chosen by a VS template when the
project was first created from the VS IDE.
Still, there's definitely clarity benefits to having that value assigned
a macro name (IDI_ICON) and using it consistently in the .cxx and .rc.
Also, it's good to have all resource numbers centralized in a single .h
file, esp. if other resources might be needed in the future, to avoid
overlapping the resource index numbers. (I assume that's what those are)
The reason I mentioned the 101 as clear text in .rc and .cxx
is that by doing so, you then don't even need the sudokurc.h file at
all.
Still, I suppose even if the sudokurc.h file were just a one liner
define for IDI_ICON -> 101, it's better to have that extra level of
indirection
than an anonymous magic number in the .rc + .cxx files..
> I was thinking we'd just try and make it match the pattern set by the Sudoku
> example, for consistency?
Right, though perhaps the sudoku example could/should be simplified;
not sure.
I guess if the VS IDE is just going to write over the .rc and .h files
with the template junk, then it's probably pointless to simplify these
files if they'll just be overwritten.
But IIRC, the "Express" versions of the VS IDE doesn't come with a
resource editor anymore; I think it's a "Pro" only feature now..
so if you click on the .rc file in the project, you get an error.
(Something to the effect of "go pro" if you want to edit resources)
So I imagine most folks would be managing the resource files by hand
now,
so perhaps the simpler they are, the better.
_______________________________________________
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
