Ok. 'cause there's written:

Quote

101 = 24 bpp (not applicable to TI-Nspire's STN LCD)

.
So apparently even 16 bit are possible? That'd be even better!
But why doesn't TI use this? SRAM can't be the reason

Speed issues ?
Also, yes, they have SRAM problems, even in 4bpp.

I suppose that this can't be solved ? (my stuff is absolutly not up to date, if it is the problem)
Don't bother on the yyyyyyyyyyyyyyyy... stuff, I know it has been solved.

Hi
Sadly you have to indicate the full path (if someone has the solution im interested :p).

So "/documents/file.tns" is the root.
You can get the program path using argv[0]

This code crashes :

Code: [Select]

int main()
{
  char *filename;

  if(show_msg_user_input("A", "B", "C", &filename) != -1) free(filename);
  return 0;
}

It runs fine for me. Update your Ndless (on the handheld) to the latest.

And I can't find any libndls directory in /ndless/ ... (I use the Ndl3ss SDK)

Okay ... in the sources, so here is the sample code :
   const char * title = "Title";
   const char * msg = "Element";
   char * defaultvalue = "default value";
   char * value;
   unsigned len = show_msg_user_input(title, msg, defaultvalue, &value);
   if (len >= 0)
   {
      printf("%s (%d)\n", value, len);
      free(value);
   }
   else
      puts("Canceled");


EDIT : second question on the go : why does libndls's refresh_osscr() crashes ?

Same, I think your Ndless version on the handheld is not up to date.

Quote from: Levak on January 21, 2013, 10:19:18 am

Indeed, you don't know its size and putting arbitrary size (here 256) is a bad programming behavior.

I don't want to be a nitpicker, but I have to disagree. In a practical context, using "big enough" buffers when dealing with arbitrary-sized strings is in many cases better than hassling around with a bunch of pointers and dynamically allocated memory. Using the latter method complexifies and bloats the code unnecessarily, gives the programmer additional responsibility (gotta compute the size of the data, malloc it, remember to free the memory, etc.), decreases the programs maintainability (as the code for that filename container is scattered around, when modifying bigger chunks better check it doesn't cause any undefined behavior), and generally the whatever academic perfection of the code doesn't outweigh the pain of dealing with such trivial stuff. We're not talking about security-critical government-class programs here, and it's not like there aren't any functions to avoid buffer overflows and whatnot.
I'm not saying you should be using statically allocated data for everything (quite the contrary usually), but for string buffers and such, a char buf[BUF_SIZE]; is usually good enough.

I know, but this applies in a context you can't control the length of the string. Here, the popup does not limit the number of characters entered, and at first it was a 256 buffer. Some people complained because it crashes when you enter a 120 chars string, and indeed ... the popup does not limit it. Thus, without having to allocate a 1024 buffer, I prefer using the dynamic length String API the Nspire uses. I think this API is the only one that runs really nicely compared to a lot of things on Nspire development.
On the other hand, there is a place in the OS where it limits the string length to 256 because the buffer is 256 : The SaveAs popup. And this has sense, I agree.

Plop,

I've been encountering some problems with Ndless' UI features. This code :

Code: [Select]

show_msgbox_2b("Title", "Text", "Button 1", "Button 2");Gives that :



And it's basically the same with show_msgbox_3b (displays a dialog box with 3 buttons) ; the labels are "Button 1Button 2Button 3", "Button 2Button 3" and "Button 3".

Not sure why, but in _show_msgbox.c, I found this
char button1_16[14];
char button2_16[14];
This explains your problem. Do not make your button text longer than 7 characters (without the \0).

If you have a text larger than 7 characters and don't want to wait ExtendeD to change the trunk, you can change it to
char button1_16[(strlen(button1) + 1) * 2];
char button2_16[(strlen(button2) + 1) * 2];

And later, change
char button3_16[14];

to

char button3_16[(strlen(button3) + 1) * 2];

And recompile libndls.a (Ndless).

Also, this code just crashes nspire_emu :

Code: [Select]

char filename[256];
show_msg_user_input("Test", "Test this", "Default", &filename);
printf("%s", filename);
free(filename);

return 0;
I think that it's a bug with Ndless ...

1) free() on a char filename[256] does crash, even in a computer program. filename[256] is a static allocation contrary to malloc.
2) filename[256] : you surely don't need this, look at the example in ndless/libndls/show_msg_user_input.c
You have to pass a pointer to your char array, but you should not initialize it ! Indeed, you don't know its size and putting arbitrary size (here 256) is a bad programming behavior.
3) Do not free if the popup returned -1, because the popup was canceled, there is no result, and your char array is not initialized. Again, checkout the sample code in ndless/libndls/show_msg_user_input.c

How did you tell the calculator that 0x34 corresponds to "Theme Editor"?

It is the case.
Remember that a Theme Editor was introduced in development builds, but sadly (or luckily for us) the string remained in the resources.

This is the simplest way to do :
A global variable "modified" (flag)
A hook that sets "modified" to 1 in every single place in the OS that modifies the folders content.
A hook in the call_doc_brower in order to have it in a singleton that checks "modified". If set to 1, re-scan everythin like TI does. If 0, just return the current content.