1)
CODE resources are completely different than other types of code resources such as DRVR, CDEF, WDEF, etc.
CODE resources are segments of an application. You split an application into segments to improve memory utilization. i.e. A code segment is not loaded unless code in that segment is to be executed. A code segment can be unloaded by code in another segment when that code segment is no longer needed. Segments are either defined by compiler directives inserted into a source file, or by defining the segments in the project and dividing source files between the segments.
https://developer.apple.com/library/archive/documentation/mac/pdf/Processes/Segment_Manager.pdf
Does Symantec C++ have DRVR, CDEF, WDEF examples?
Generally, a code resource DRVR, CDEF, WDEF, etc is a separate target of a project. The target is a resource. The resource is then made a dependency of the application target so that it will get inserted into the resource fork of the application.
2)
Depends. How much work does the Control Manager do for you?
Drawing controls is not as simple as a single draw. You need a device loop to handle drawing to multiple screens of different pixel depths (if you wanted to support Color QuickDraw).
It would be a pain to do the whole white note around the black ones
White keys of the keyboard are composed of one or two rectangles. Or you can make a region. The region is composed of one or two rectangles so they won't be too large in memory.
It looks like the left edge of your invert rectangle is two pixels too far to the left. Or three pixels if you want the inverting rectangle to be surrounded by white pixels.
The bottom edge is one pixel too far to the bottom. Or two pixels if you want the inverting rectangle to be surrounded by white pixels.
I just tested it on real hardware and so far, the amount of logical tests isn't enough to make it noticeably slow. It's still very snappy indeed.
I think the number of tests needed is one to four, since the keys are mostly equal width.
Divide the mouse horizontal position by the width of the white keys to get the white key index. I suppose the black line dividing white keys should correspond to the white key to the right of the line.
The mouse vertical position determines if you need to test the modulus of the division to determine if a black key is pressed. If the width of a key is 8 then a mod < 3 should test for a black key on the left and a mod > 5 should test for a black key on the right. A mod value in between represents the white key.
For each white key, you should have a bit that states if the right side of the white key has a black key. For the left side of the white key, you would check the value for the white key to the left.
It appears that the position of the black key on the right side of a white key is variable (by one pixel?). An extra bit is required for that info. This extra bit is added to the mod check described above.
