Is there a way to read a resource piece meal?

I threw a couple of things into Resources of my project (running on USBizi). However, when I read them back at runtime via the following:

string s = Resources.GetString(Resources.StringResources.App)

it throws an Out of Memory exception. So is there a way to read the resource in a piece meal fashion, perhaps, like, 1kb at a time?

If not, are there any alternatives to storing the resources elsewhere (e.g. i do not have an SD card in my design).


No, you need to split your strings before adding to resources but why do you have such large string or where is memory being used?!

The resource is not that large, less than 2k. But I need to manipulate it and eventually send it through the comport.

Something happens inside the Comport code that generates the OOM. The function takes a string parameter (data), converts it to a byte array and sends it to an instance of SerialPort (sp). The .Length of the data string is 1989

Note the following code and Debug.GC(false) outputs.

                // 15228
                // 12300 ??? 
                byte[] buffer = StrToByteArray(data);
                // 10332
                sp.Write(buffer, 0, buffer.Length);  -- it blows up here.  

So I am guessing that some data handling is going on in the SerialPort object that requires more memory that is available.

If I reduce the data parameter to 1000 bytes, it never crashes, ever.

I should mention that I am using GHI sdk v1.08 from 8/2010.

rgelb, That’s a really old version of the SDK. Have you tried this on the current version to see if this is perhaps a problem that has been fixed? If you can’t test it for some reason, please post your StrToByteArray() also and I’ll test it. Also, please use code tags when posting code.

Here is StrToByteArray

        public static byte[] StrToByteArray(string str)
            System.Text.UTF8Encoding encoding = new System.Text.UTF8Encoding();
            return encoding.GetBytes(str);

But that is not where it blows up. In fact it works exactly as I would have expected. Before the call, there was 12300 bytes available, after the call 10332, because it converted a string of length 1998 to a byte array.

The problem is in SerialPort.Write and possibly in SerialPort.DiscardOutBuffer methods.

I’ll give it a shot with a later version of the SDK (was really trying to avoid it).

What if you Write() out buffer 1000 bytes at a time?

I wanted StrToByteArray() so I could test your code :slight_smile: Setting up now…

I’ve been able to Write() out over 4K. So, if this is a problem related to Write() then it has been corrected. Definitely try on the latest SDK.

I think the point is to try it while only 10k of RAM is available. Was that your situation?

That will take a little longer to setup. Gotta get to bed tonight. I’ll try to recreate that situation tomorrow. In the meantime, you might try using a loop with the offset and length parameters to write out 1K at a time?