Skip to content

Name fields are weird #12

Open
Open
@kg583

Description

@kg583

The interpretation of the name field varies heavily with the entry type. It is "most often" best to think of the name as a single token, and if not that then a font string, though there are exceptions:

  • For lists (001h and 00Dh), if the second byte is <6 it tokenizes it, if 040h it prints "IDList", else it just uses the font for up to 5 chars.
  • For programs, appvars, and groups (005h, 006h, 015h, and 017h), it displays a font cstr of up to 8 chars.
  • For Window settings (00Fh, 010h, and 011h), it displays a hardcoded string "Window", "RclWindow", or "TblSet" respectively (or a localized string)
  • And Images (01Ah), it tokenizes 0EF50h + [byte two].

(summarized by @LogicalJoe following lots of reverse engineering)

The lib currently treats every name as tokenized, which agrees with the font and some of the special cases for the most part but begins to fail for things like GDBs.

  • Lists tokenize for L1 - L6, have "IDList" for some reason, and then use the font otherwise (up to 5)
  • Programs, appvars, and groups use the font (up to 8)
  • Settings types use hardcoded strings
  • Images tokenize the first two bytes
  • Everything else tokenizes the first byte (new default)

Metadata

Metadata

Assignees

Labels

bugSomething isn't working

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions