Sorry if this is the documentation. It’s probably something programmers just know! Sadly, I’m no programmer.
I’m adding some rows to a table, but not all fields are populated. Using the – designation instead of leaving a field literally empty is the recommended practice, and my table begins this way. But how do I update an entry with -- during play? Or is Inform already doing this when I make a new row? This is not accepted:
now subtable entry is --;
it also doesn’t accept now subtable entry is "--";
…Which makes sense, because the column is for table names, not text.
It compiles OK. This is a runtime problem. All of my text and text substitutions work fine. It could be something else, but I thought I’d ask about writing -- in new rows before going much further.
Should I be updating entries with this? If so, how?
If I’m understanding correctly, you’re wanting to take an entry that was previously filled and make it blank. If that’s the case, you’ll want to use the phrase blank out (a table entry), as documented here.
If you’re looking to add new rows to a table during play, as far as I know that’s not supported. However, you can have just about as many blank rows as you want at the start of play and fill in individual entries later, through the phrases listed on that same page.
Thanks. I’ve been blanking out rows and updating entries, thanks to the documentation. I misspoke when I said “adding rows to a table.” I meant “updating fields in blank rows.” Apologies!
I’m asking if I need to populate empty table fields with the -- designation during this process. It seems so, because the documentation recommends it, and the run-time errors that I am receiving are concerned with blank fields. Then again, Inform may be handling this automatically.
My questions are twofold:
and
If not, I must have a different problem, and I’ll go back to the drawing board.
As in, do you need to specify that you’re leaving some entries blank while filling other entries in the same row? That shouldn’t be necessary, since they’re already blank.
What are the runtime errors you’re seeing? From my (very limited!) understanding, @OverThinking is right that you shouldn’t need to worry about telling Inform that already-blank fields are blank, so I wonder if something else is going on.
This is related to the menu business, as you might guess. I was hoping this was something easy that I was overlooking, but I’m probably just out of my depth. I may just need to contact the author.
Inform allows us to create tables with blank entries, having no value at all: sometimes these are written –, but sometimes they are literally left blank in the original source text. We are not allowed to read such an entry, and this is the problem which turns up if we do. (Whereas we are allowed to write to it, making it no longer blank if we do.)
OOPS! got this backwards
There are three columns in use.
The first is always populated. Either the second or third is always populated, but never both in the same row.
When column 2 is blank, an error always occurs.
When column 3 is blank, an error never occurs.
I’m probably just breaking the extension by cracking open the master table (the table of contents) during play. I accept full responsibility!
e: mistakenly typed “row” insteand of “column”. Also screwed up the column 2 and column 3 order.
-- means blank in Table definitions exclusively. And despite how much Inform hates a vacuum, the column entry values in a blank row don’t get their kind’s default the way a variable would. They’re basically null pointers and an attempt to read them will result in a runtime error.
If you have code operating on what might have blank columns, you can check it for blankness before accessing with if there is [...].
Or, when you update the row, you could populate text columns with “” and number columns with 0, etc., if that’s easier to deal with.
I think I’m at the end of the road. Dumping the contents of the table works ok. Finding a blank field with an if statement works ok. Manually blanking the field works. I tried making a placeholder table, too, since the column requires a table name. So I think the updated records are fine. There’s something else going on.