Commander X16

Now there is an input_str function...

That took up a lot of space. Library size went from 900 bytes in 0.7 to 1008 now in 0.8


 

Whohoo you did it! Now VTUI Library seems almost maxed out. Really impressive. Thanks!

the input_str() routine, does it return the input string in petscii or in screencodes?

2 minutes ago, desertfish said:

the input_str() routine, does it return the input string in petscii or in screencodes?

The string is returned in PETSCII. I will update the documentation to make that clear.

Playing some more with input_str.... :

• 
  entered string in buffer seems to be terminated by a zero byte (I like this!)
  


• 
  ... this probably means you want to allocate 1 byte more in your input buffer to have room for this.  Maybe good to document this too
  


• 
  after pressing enter, the cursor remains visible. I expected it to disappear
  


• 
  i cannot enter petscii symbols (or capitals when in lowercase character mode) ?
  

@desertfish

• 
  String in buffer is NOT zero terminated. If you type a string an press backspace before return, you will see
  


• 
  I actually meant to document my way out of the cursor not disappearing, but I may have to just use the 8 extra bytes and hide it before return
  


• 
  input_str supports the same characters as print_str
  

About zero termination, I'm a bit confused then, because I see this :



my input buffer at $0920 was fully filled with 20 question marks $3f,  I typed my name (and some garbage that I  backspaced), and those zeros really did appear ?

12 minutes ago, desertfish said:

About zero termination, I'm a bit confused

I share your confusion. I am currently looking into why those 0's are added to the buffer.

@desertfish, I figured it out. 

I store anything that is returned by the GETIN Kernal function in the buffer, but only if the character is within the allowed range is the length incremented. 

This means that so long as the user has not used all allowed characters, you will essentially have a zero-terminated string, but if the user uses the full allowed length, there is no zero added to the end of the buffer.

 

I have been toying with the notion that maybe I could use a kernal function to do the conversion between petscii and screencodes. Unfortunately it seems that the only place the kernal converts from petscii to screencodes is in a function that also prints the character to the screen.

My next thought is that I could possible make use of kernal functions in the VTUI library instead of writing directly to VERA. I am fairly sure that if I change the library to use kernal routines, the size will be decreased a fair bit and it would most likely be better at converting between petscii and screencodes.

What are your thoughts? Would there be any problems in using kernal routines instead of writing directly to VERA?