I opened the module for the first time and named a new whatever it is but can't see how to proceed with it. The userprop I named is listed on the left and the window on the right is empty. Is my naming of it the same as saving it? Will it now be included in my project? How do I refer to it in a script?

rpitcairn wrote:I opened the module for the first time and named a new whatever it is but can't see how to proceed with it. The userprop I named is listed on the left and the window on the right is empty. Is my naming of it the same as saving it? Will it now be included in my project? How do I refer to it in a script?

That's quite simple.Once you've defined the userprop as you did, you can edit its content in the field at the right.For instance :type "utest" into the "define" field (if you want more info about "define", shift-click this word, as usual, it will open the LG).type enter, the word "utest" is now in the list and selected. At this time, the userprop is just defined but is still empty (that's why the field at the right is empty).type "abc" into the field at the right, type enter. The userprop has now a value.

Now for testing it, in the message box :type : the utest of this cd. Will return "abc"type : set the utest of this cd to "def". and you'll see "def" in the uprops module.

The field at the right is used to edit the value of the userprop selected in the list at the left. Once defined, a userprop is used like any property, you can set it or get it. Of course, you can also define or undefine userprops by script (see these words in the LG).

This module, as other MPI modules, sticks to the context. If one object is selected with the pointer tool, the uprops module will show you the properties of this object (if several objects are selected, the first one is edited). If no object is selected, you get the userprops of the cd or the bg depending of the editbg. For the userprops of the window and project, use the popup menu.If you want to see (or edit) the userprops of an object with the browse tool, put the mouse on this object and hold down ctrl-opt (like you would do cmd-opt for the script). Or use the contextclick popup menu in the topwindow or on an item of the Overview module if the object you want is not in the current card of the topwindow. You can also copy the selected userprops using the popup menu, then paste them into another object (copy/paste of userprops is done only with the menu, cmd-C/V don't work because they're used to copy/paste the selected object)The long id of the edited object is shown in the field at the top.

Thank you Stephane. I understand. I can use the userprop like any container and once created will be part of that project, right? That is, will be saved between "quits". And I can make as many as I want, right? And they will hold formatted text?

It's not a joke, I really had problems with more than 32768 userprops and I bitterly complained. That's true.

BTW, a few other things to know about userprops.They are loaded in RAM only when the object to which they belong is loaded. So, you must take care of defining them in an object which remains visible from where you're using them. If you want to access them from all the cards, define them in the bg, the wd or the proj. You can still access userprops of other objects but it will be much slower because this will require disk access.

Contrary to the other "predifined" properties they may be handled from a name in a variable.put "myprop" into propnamedefine propname of this cdget the propname of this cdYou can't do (alas !)put "rect" into propnameget the propname of mygrc

Thus, it is highly recommended, when defining a userprop with a litteral, to quote it. It would work without quotes as long as you don't have a variable with the same name but if you declare one later, you'll have some surprises.

The keyword "the" is requiredyou can do get rect of mygrcbut you must doget the upropname of mygrc.

rpitcairn wrote:Well I can't imagine how you could have need for so many userprops but I won't laugh any more.

I worked on this when I made the table module. If you want to see some tables, open project "MPI Samples:Tables Sample:Lorentz 2" in the moduloPI_Folder you downloaded.I was looking for a fast and handy data structure for storing the data of the tables.

Since, as I said in a previous mail, userprops may be handled by their name in a variable, it was easy to compute systematic names like "mydata.c.r" where c and r are the number of the column an the row respectively and have one userprop containing the data for each cell of a table.I made some speed tests. The red curve is the time required for storing data into a usual lines of items structure (number of ticks in ordinate, number of cells in abscissa). The green curve (look carefully along the x axis) is the same thing done with userprops.

speed.jpg (27.62 KiB) Viewed 4559 times

I calculated an average 175 times faster, growing with the number of cells. Worth considering, don't you think so ?The problem is that, since I needed to access these data from any card of any window, there was no other choice than defining userprops of the project, otherwise, I came back to access them on disk.But because of this limit of 32767, I gave up with this technique. Who would want a spreadsheet limited to 32767 cells ?AFAIR, I finally made a line and item structure whose item length is known in advance (and filled with spaces if empty) and thus allowing to calculate the chars where the data are stored (I already explained in another mail why accessing chars is much faster than items and lines).