Zugg Software :: View topic

Wanderer Joined: 03 Aug 2005 Posts: 84

These are a very useful tool for random things, but they are limited to 64 characters, why is that? We are not on 486s with 32mb of RAM anymore, give use 256 char strings in out string lists, or even better unlimited.

Posted: Mon Feb 05, 2007 12:02 am

First I thought you meant in total:

Wanderer Joined: 03 Aug 2005 Posts: 84

silly Fang Xianfu, those are database variables not string lists...

Create a new variable and set its type as string list in the GUI. Click off of it, then back on it again so the interface will refresh. Then start typing in the first slot. At 6 chars it will beep and not allow you to type anymore.

Between my last post and this one, i actually learned the workings of DB variables so I could use them instead. Now to figure out this periodic event without a #wait thing that I've heard so much about.

Speaking of DB variables, it would be nice if the GUI did not select all in the current record on the autosave. its annoying to type in a value just to have it disappear for the last two or three characters.

Posted: Mon Feb 05, 2007 1:51 am

No, those really are string lists. If you look at my second example, you'll actually see I've explicitly defined my own string list. In addition, record vars use #addkey, not #additem.

That's a much better description of your problem - it actually lies in the String List view in the package editor. I can actually confirm that, it's cutting off the items at 64 chars for me too. I added some 100-char items to a list, then viewed them in that mode and it cut them all off at 64 - they still contained 100 characters if I used a function or @var.n to retrieve them, but that view wouldn't show their full length.

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

There's no multi-line support for that part, I don't believe. Thus, you only see the first-line portion before CMud has to wrap to the next line. #MESS in ZMud as well as some of the popup commands/functions (#PICK/%pick(), #PROMPT/%prompt(), etc) had this issue as well, even though the parser easily was able to handle the multi-line text.

Posted: Mon Feb 05, 2007 6:18 am

What's this got to do with multiple lines? Check out this screenshot. If you try to type any more into either of those boxes, you get that "dung!" noise windows makes in every program when you're typing somewhere you can't, or when the box is full.

Wizard Joined: 11 Jul 2002 Posts: 1265 Location: USA

If the GUI thinks it is limited to 64 chars on a line it will give that noise, and will cut off loading from your actual variable at that point as well. Unless Zugg added something in the code that automatically caused things to be wrapped to the next line, and for all I know he did, the GUI would not store anything else after that point. If he did but did not create a way for us to look at that next line what Matt said is possible. Though unlikely.

Regardless this needs to go into the Beta forum as a bug.

Posted: Mon Feb 05, 2007 7:59 pm

Added to bug list. As mentioned, it's a bug in the GUI for entering string lists. There isn't any internal limit on string list item length, so it's just the grid field in the package editor that has the problem.

And yes, multi-line items in a string list are not currently supported by the GUI. You can create them using %additem or #ADDITEM and manipulate them in scripts, as long as you don't need to edit them interactively in the package editor.