Unable to utilize TinyFnt embedded resource

[dlkay0]

Details about Problem

nanoFramework area: Visual Studio extension

VS version: N/A

VS extension version: <= 1.0.3.87

Target: N/A

Firmware image version: <= 1.0.4.390

Device capabilities output: N/A

Detailed repro steps so we can see the same problem

1. Add a .TinyFnt embedded resource

2. Observe that ProcessResourceFiles.Entry.typeDescriptions defines the datatype to Microsoft.SPOT.Font when it creates the *.Designer.cs file for the resource file.

If this would define the return type as byte[], then it would allow the consumer to embed TinyFont resources and handle the data rather than force inclusion of Microsoft.SPOT.Font and dependencies.

Other suggested things

I also recommend adding a nanoFramework Embedded Resource.resx template that automatically sets the "Custom Tool" to nFResXFileCodeGenerator. It took a few minutes to figure out why VS wouldn't create a valid *.Designer.cs file.

Matching changes are also required in nf-interpreter\src\CLR\CorLib\corlib_native_System_Resources_ResourceManager.cpp to return the byte[] instead of treating it as a Font (which is to _ASSERTE(false); and crash the uC).

Sample Project (if applicable)

EmbeddedResourcesInExtension.zip

[dlkay0]

Changing the HelperMethod data type in the generated code won't impact the VS APIs; only the generated code that will run in the uC.

[dlkay0]

Here's an ItemTemplate for a nanoFramework Resource file...
nanoFramework Resource File.zip

[josesimoes]

This picks up #121.

[josesimoes]

@dlkay0 the code to handle fonts at the native end has already been added in the develop-ui branch.
See here and here.

Questions:

• Does adding that font.cpp file and renaming the namespace in the VS resource generator makes this work?
• On your suggestion above to make fonts accessible as byte[]: would that make it easier (or more efficient) to access embedded font resources? I'm asking because the way bitmaps were handled in .NETMF is similar.
• Can we ditch (or isn't that required at all) the properties and methods that are currently available in Microsoft.SPOT.Font?

[dlkay0]

@josesimoes Font and Bitmap in Graphics are tightly coupled in both directions. Font contains a Bitmap and takes a Bitmap as a parameter to StringOut while Bitmap has the DrawText method which simply passes through to StringOut on a Font which is passed as a parameter. Who's responsible for rendering a font on what "surface"?
If DrawText and DrawTextInRect were refactored into Font, then at least Bitmap wouldn't require a reference to Font.
If Font had a private implementation of Bitmap, then Font wouldn't require a reference to Bitmap. It's not as if Font needs any ability to render lines, circles, etc. or to persist as Gif, Bmp, Jpg, Png formats.

That being said...to answer your questions...
1
It does appear that adding font.cpp will give us the ability to render fonts, but no method for loading them.

2
In order to load String, Font, and Bitmap resources, we also need to augment the switch statement in ResourceManager.GetObjectInternal___OBJECT__I2 to create instances as in NETMF

However, including this code means the definitions for CLR_GFX_Bitmap and CLR_GFX_Font are required whether or not you need them. (oh the pains of strongly-typed resources)
This is where returning a byte[] instead of the Font/Bitmap allow for more flexibility with less required code at the cost of a little type safety. Of course, we'd also need constructors which took byte[] in Font/Bitmap.

3
The Font code on that branch is more complete than what I cobbled together and it has been proven in NETMF for some time. Since the code is already there, it would be wasteful not to use it.

So here's what I'd recommend:

1. Return byte[] from ResourceManager.GetObjectInternal___OBJECT__I2 to reduce dependencies.
   (Remove the TinyResourceFileHeader and TinyResourceHeader)
   -or-
   Allow ResourceManager.GetObjectInternal___OBJECT__I2__I4__I4 to succeed and return byte[] for "well-known" types (String, Bitmap, Font) to enable ResourceManager.GetBytes to work. Calling NANOCLR_SET_AND_LEAVE(CLR_E_INVALID_OPERATION); is the root of my problem. The Resource Manager is prohibiting me from seeing the binary content of the TinyResource that I added to the project.

2. Implement constructors for Bitmap and Font which take a single byte[] parameter. If the TinyResource magic number header is found, then the TinyResourceFileHeader and TinyResourceHeader can be parsed/validated; otherwise just load the Bitmap or Font.

3. Give Font it's own implementation of a Bitmap to load the character bitmaps so a reference to Bitmap and Graphics in general is not required.

4. Move DrawText and DrawTextInRect from Bitmap to Font to consolidate responsibility and reduce coupling.

5. Declare the SetPixelsHelper delegate in a normally-included header so Graphics and Font can both leverage it.

And to wrap up with a question...
Should Graphics.cpp and Graphics.h be renamed to Bitmap.cpp and Bitmap.h throughout since that is really what is defined in there? This may lead to renaming the Bmp.* files and the like to BmpFormat.*...

[josesimoes]

@dlkay0 WOW!! impressive!! 😄 👏

Let me chew this.
Also would like to ask @TerryFogg input on this. He's the one doing the heavy work on UI branch.