Add option to specify resource type

[delphidabbler]

Currently all files are stored in RT_HTML resources. Give option to specify resource type for each file: either by number (say #999 format) or string. Could have a few predefined: RCDATA, HTML etc.

This should also help in avoiding duplicate file names = names only have to be unique within a resource type.

[delphidabbler]

All predefined Windows resource types are listed in this document: https://docs.microsoft.com/en-us/windows/win32/menurc/resource-types

[delphidabbler]

Allow this to be provided on a command line basis or file by file.

Command line

Allow for a command, say -t:xxx that applies type xxx to all files on the command line, or in the manifest. But allow this to be overridden on a file by file basis.

File by file

Optionally prefix the file name with a resource type, like this:

• @html:index.html - RT_HTML resource.
• @rcdata:readme.txt - RT_RCDATA resource.
• #33:foo.dat - custom resource type number 33.
• CUSTOM:bar.dat - custom resource type named "CUSTOM".
• about.png - default resource type.

From the above we have an optional resource type followed by a colon then the file name.

Where no resource type is supplied, then the default RT_HTML is used, unless overridden by the -t command, when the specified resource type is used by default.

Where a resource type is specified there are three types:

• @ prefix. Following name is a predefined resource type: html for RT_HTML or rcdata for RT_RCDATA.
• # prefix. Following decimal number is a numeric resource type number.
• No prefix. The name is a custom resource type name.

[delphidabbler]

File by file

Optionally prefix the file name with a resource type, like this:

• @html:index.html - RT_HTML resource.
• @rcdata:readme.txt - RT_RCDATA resource.
• #33:foo.dat - custom resource type number 33.
• CUSTOM:bar.dat - custom resource type named "CUSTOM".
• about.png - default resource type.

Note that we will need to adapt the above to coexist with the need to set the language id for a file too - see issue #2.

Could use something like this
@l:0x456;t:@html;index.html

The @ symbol starts the "parameter" section. Parameters are separated. Parameters start with a letter to identify it, followed by a colon and then the parameter value. The last part is always the file name.

[delphidabbler]

Another approach, that is more readable in manifest files, could be to enter the plain file name followed by the command in the same format as used on the command line.

On the command line this will be a bit unwieldy. It would also imply that to affect the whole command line commands would have to precede the first file name. Subsequent commands would affect the file name preceding it.

Example of command line:

Htmlres -t:@rcdata foo.dat bar.dat index.html -t:#27 data.xml about.gif -t:fortytwo

Here, the default resource type is RT_RCDATA. This applies to foo.dat, bar.dat & data.xml because none have these have a trailing override command. index.html has a numeric resource type of 27 while about.gif has resource type "fortytwo".

Here is an example manifest file that has the same effect as above, providing the command line has a single -t:@rcdata before the command that includes the manifest file:

foo.dat
bar.dat
index.html -t:#27
data.xml
about.gif -t:fortytwo

which is much easier to read.

[delphidabbler]

Here is an example manifest file that has the same effect as above, providing the command line has a single -t:@rcdata before the command that includes the manifest file:

foo.dat
bar.dat
index.html -t:#27
data.xml
about.gif -t:fortytwo

It would be helpful if the manifest file could be self contained and not have to rely on the default resource type being set on the command line.

To do this commands file could be permitted at the top of the manifest that affect all files. So the above file would become:

-t:@rcdata
foo.dat
bar.dat
index.html -t:#27
data.xml
about.gif -t:fortytwo

[delphidabbler]

The above suggestions seem either unwieldy or counter intuitive. Here's an alternative approach, based on the concept of a current context that stores the current state for each command. We also have a stack of contexts.

There are three contexts:

1. Command line context: top level context that applies to the whole command line. Pushed to stack at start of processing & popped at end.
2. Manifest file context: one for each manifest file, created & pushed to stack when manifest command is encountered & popped from stack at end of manifest file.
3. Manifest line context: created for each line of manifest, pushed to stack at line start and popped at line end.

Each context inherits its state from its parent. Command line context gets given default program state.

Every filename encountered is given the current state of the current context while every command encountered changes the state of the current context.

From the above it can be seen that commands affect all files that follow them and the state of any child context created after them.

The current context at top of stack.

We'll need a record to store current state and a stack class to store stack of state records.

As an example, consider the following command line:

1.html 2.html -t:#101 3.dat -mman1 4.dat -t:@html -mman2 5.html

Where man1 has content:

1-1.dat
-t:@rcdata 1-2.dat
1-3.dat
-t:@html
1-4.html
1-5.html

and man2 has content

2-1.html
-t:#42
2-2.dat

Here's how the line is proceesed:

1. Command line context created & and set to default state -t:@html
2. 1.html & 2.html are given type RT_HTML
3. -t:#101 changes command line state to type #101
4. 3.dat is given type #101
5. -mman1 is processed, inheriting state = type #101
6. 1-1.dat is given type #101.
7. -t:@rcdata changes state for current line only, so 1-2.dat is given type RT_RCDATA
8. 1-3.dat is given type #101
9. -t:@html changes manifest state to RT_HTML
10. 1-4.html & 1-5.html are given type RT_HTML
11. End of man1 causes state to restored to type #101
12. 4.dat is given type #101
13. -t:@html changes command line state to RT_HTML
14. -mman2 is processed, inheriting state = type RT_HTML
15. 2-1.html is given type RT_HTML
16. -t:#42 changes manifest state to #42
17. 2-2.dat is given type #42
18. End of man2 causes state to restored to type RT_HTML
19. 5.html is given type RT_HTML

Of course any other command that affects state can also be used.

Actual command lines are unlikely to mix file parameters and manifest files but they can do, so some logic needs to be established. Actual manifest files are likely to begin with commands so the commands on the command line can't change, for e.g., the resource type of files.

🗒 Notes about manifest files

Need to test whether a line contains a filename before creating a new context:

• no filename => no new context
• filename present => start line context

Multiple commands are allowed on any line. Where a filename is present commands should (must?) precede the filename.

❓ Allow multiple filenames on a line too? Commands work as if this was a command line?

[delphidabbler]

Just to clarify, the stack is a stack of contexts, not commands.

The process is:

1. At the start of command line processing, create a record with system default values for commands. Push onto stack. Pop the stack when command line processing is finished. Stack should then be empty.
2. As each manifest is started, create a manifest file context that is a copy of the top of the stack and push that onto the stack. (If we only allow one level of manifest files then the top of stack being copied is the command line stack.) Once the manifest file has all been processed, pop the stack.
3. As each manifest line is started, create a manifest line context that is a copy of the top of the stack and push that onto the stack. (If we only allow one level of manifest files then the top of stack being copied will be the manifest file context.) Pop the stack when the line is finished.

In doing this we only need to read command values from the top of the stack. When a command is encountered the relevant value at the top of the stack should be updated.

The above process lends itself to allowing multiple levels of manifest files, i.e. permitting a manifest file include a further manifest file. The lower level manifest files will inherit its default values from the parent file.

Additionally, if we keep track of whether the command line, manifest file or manifest line are being processed the error messages could be more informative about the location of any errors.