Program "project" structure - how to use?

[komame]

The errors described below pertain to firmware 14730 and may be fixed in subsequent versions.

I conducted more detailed tests. In general, resource files can be created directly on the HP Prime, but sometimes it requires a bit of tinkering, and it's much more convenient to upload them using the Connectivity Kit. You can't create new resource files from the program, but you can modify them. The Resource() instruction (without argument) returns a list of all resource files along with their size and type.
Once a resource file is created on the HP Prime, you can't change its name, but you can copy it to another one with a different name.

Resource files for source code.
You can create additional PPL or Python files. So far, I haven't been able to refer to a program placed in a Python resource file (I tried in various ways, but I always received the message " '_name' is not defined "), so I won't describe it. If someone managed to call a subroutine from an additional Python file in a project, please share that information in this thread. However, an additional PPL file works without any issues, and I'll discuss that.

In the additional PPL file, you should place functions that you can reference from the main file. Each file can have its own #pragma settings, and when a PPL function is called from the main program, it will behave according to the #pragma settings of the file in which it's located. When it return from the procedure to the main program, the #pragma settings of the main program will apply again. This is intuitive and works correctly.
Syntax errors in PPL files are checked during "CHECK," and if there's a syntax error somewhere, the view is automatically switched to that file with the cursor set to the line of the code with the error.

I haven't found any bugs for PPL resource files, at least during my tests. However, that doesn't mean there aren't any. Still, everything worked stably during my tests.

Graphic files.
In the Connectivity Kit, there are three types of files to choose from: png, jpg, and bmp.
Resource files for graphic files can also be created directly on the HP Prime. It's important that the image you want to load into the resource is in G1.
For example, give the following commands in the HOME:

Code:

DIMGROB(G1,20,15,255); //put a blue rectangle into G1

Then create a new .png file in the project, and when you enter that file, choose LoadG1 from the menu. This will load the G1 image into the graphic resource you're in.

If you have a graphic resource, you can assign it to any graphic object G0-G9:

Code:

G1:=Resource("png1");

You can also copy graphic resources between each other:

Code:

Resource("png1"):=Resource("png2");

Unfortunately, such copying often works unstably and sometimes causes crashes. However, there is no problem using these graphic resources as read-only files, as in this scope it works stably and also allows for a significant reduction in the size of the program, especially if someone doesn't want to create a HP Prime App and uses ICON to store graphics within the program code.

Binary assets.
These files allow you to store any binary data, which you can access as lists of bytes. It's very similar to AFilesB.
Creating a file from the Connectivity Kit gives more editing options because you can enter data in both hexadecimal and decimal formats. You can also choose a 1-byte, 2-byte, or 4-byte input mode. If there's even one invalid code, the file simply won't go to the HP Prime, and no message will appear, so you need to verify the data thoroughly before entering it.
Unfortunately, binary assets are the most unstable part of this solution. Sometimes, creating files from the Connectivity Kit works, and sometimes it doesn't (often only the last byte makes it into the file).
Creating binary assets directly from the HP Prime works better, but in this case, you can only enter 1-byte hexadecimal values. Once you've created a binary file, you can change its content from the program, just like with AFilesB.

I've noticed a problem with reading binary asset files into a list.
For example if we have 3 bytes (hex) 010203 in the binary file "B1," you need to call the command to read all the file:

Code:

Resource("B1");

This should read three bytes, but an additional byte appears at the end (garbage).
result: {1,2,3,?} - the '?' is an extra byte that should not appear. It may have various random values.

One of the syntax options says: Resource("name", start, end), so let's try to force reading three bytes (which is the byte range from 0 to 2):

Code:

Resource("B1",0,2);

Result: {1,2,3} - and in fact, we read three bytes, without a garbage byte at the end, but we had to explicitly specify the range for it to work correctly.
However, there is also an issue with this syntax because if we request to read more bytes than are available in the resource, that additional byte will also appear.

So according to this logic, in the third parameter, we need to provide 1 in order to read two bytes:

Code:

Resource("B1",0,1);

Result: {1,2}

What if you want to read 1 byte? I don't know because when the 'start' is equal to the 'end', we receive an empty list as a result. This is a clear bug, at least for Resource("name", start, end) syntax.
As a workaround for reading a single byte, you can temporarily use a different syntax: Resource("name", pos). However, when working with byte ranges, you must use the syntax Resource("name", start, end), and when the range becomes one byte, you'll need to change the call to Resource("name", pos), which can be cumbersome because it requires continuous range length monitoring.

Of course, you can also modify these files:

Code:

Resource("B1"):={100,101,102};

Unfortunately, despite having several syntax options for modifying resources, the one mentioned above is the only one that works, as Resource("name", start):={data} and Resource("name", pos):=data always result in an 'Error: Invalid input'.

An important piece of information is that although resources behave like files, they are actually stored in RAM (so they are not files). This seems to be an interesting solution for storing various large amounts of data, rather than keeping them in the source code.

Tim, thank you for this solution. It seems to be great, but someone still needs to fine-tune it to make it fully functional.