Setting text properties for a field on all cards

[Ramanoir]

A real newbie question regarding SuperCard visual interface scripting, on which I am stumbling at this moment, as I can't find the relevant topic in the documentation. 

How can I script the text properties of a background field that will affect all cards of a window and hopefully will be preserved during the creation of new cards? 

Or do I need to go through all cards individually of a project to set unified text properties? 

Many thanks for the enlightening!

André

[MARK LUCAS]

Could you be more specific about what you're trying to do, and what's happening (or not happening) that you didn't expect or don't like?

-Mark

[André Tremblay]

Hello Mark, 

First of all, thank you for your ever presence to the SuperCard community! 

I wish to share a recurrent though that crossed my mind so many times during the last months while doing more intensive sessions of SuperTalk scripting; how wonderful the SuperCard environment is and how shameful the lack of support from Apple Corporation is toward its long time users as it is parting away from its legacy for “real intelligence”!

Le 06-févr.-2022 à 02:51:06, 'MARK LUCAS' via SuperCard Discussion <superca...@googlegroups.com> a écrit :

Could you be more specific about what you're trying to do, and what's happening (or not happening) that you didn't expect or don't like?

Well, I have to admit that my case is most likely unusual, being in the process of converting a previous HyperCard suite of projects, I have hundred of stacks or converted projects that consist of one window, one background and one field that contains list of items in the form commas' delimitated text strings. I would estimate that the cumulative number of cards of those project is well over a million. 

Usually those projects are not accessible to the users. For some reasons, now I wish to modify the presentation of those cards into a more users' readable format than the legacy HyperCard format that originated during the heydays of the MacPlus 512K.

To achieve that goal I've created a model project from which I wish to replicate the visual presentation to all the selected projects. I wish to be able to perform theses changes whenever necessary. 

For instance, to extract the relevant window, background and card properties, I'm testing this function: 

function ExtParaFenetre -- ExtParaFenetre(ChHFSProj) L8239 -- 20220205 20220204

   local ChHFSProj=param(1),LiParamsFe=Param(2)

   local ParaFene01,ParaFene02,ParaFene03,ParaFene04,ParaFene05,ParaFene06,ParaFene07,ParaFene08,ParaFene09,ParaFene10,ParaFene11,ParaFene12,ParaFene13

   put eC(the rect of window ONE of project ChHFSProj) into ParaFene01

   put the resizable of window ONE of project ChHFSProj into ParaFene02 --  TRUE

   put the style of window ONE of project ChHFSProj into ParaFene03 -- standard

   put the autoBackSize of background ONE of window ONE of project ChHFSProj into ParaFene04 -- true

   put the autoResize of background ONE of window ONE of project ChHFSProj into ParaFene05 -- TRUE

   put eC(the rect of fld ONE of window ONE of project ChHFSProj) into ParaFene06

   put eC(the anchorData of fld one of window ONE of project ChHFSProj) into ParaFene07 -- "Left,Top,Right,Botton" -- ∆ The property should be defined first

   put the dontWrap of fld ONE of window ONE of project ChHFSProj into ParaFene08 -- FALSE

   put the lockText of fld ONE of window ONE of project ChHFSProj into ParaFene09 -- FALSE

   put the textFont of fld ONE of window ONE of project ChHFSProj into ParaFene10 -- Geneva

   put the textsize of fld ONE of window ONE of project ChHFSProj into ParaFene11 -- 14

   put the textstyle of fld ONE of window ONE of project ChHFSProj into ParaFene12 -- PLAIN

   put the textAlign of fld ONE of window ONE of project ChHFSProj into ParaFene13 -- LEFT

   return merge("[[ParaFene01]],[[ParaFene02]],[[ParaFene03]],[[ParaFene04]],[[ParaFene05]],[[ParaFene06]],[[ParaFene07]],[[ParaFene08]],[[ParaFene09]],[[ParaFene10]],[[ParaFene11]],[[ParaFene12]],[[ParaFene13]]")

end ExtParaFenetre

I am sure there should be a better way for doing it. I know that the use of the rtfText property for the text properties management would more efficient, I come to it later on. 

And then to modify the target project with the equivalent test command:

on ModiFenetre -- ModiFenetre ChHFSProj,LiParamsFe L8261 -- 20220205 20220204

   local ChHFSProj=param(1),LiParamsFe=Param(2) 

   local ParaFene01,ParaFene02,ParaFene03,ParaFene04,ParaFene05,ParaFene06,ParaFene07,ParaFene08,ParaFene09,ParaFene10,ParaFene11,ParaFene12,ParaFene13

   CoerParams LiParamsFe,@ParaFene01,@ParaFene02,@ParaFene03,@ParaFene04,@ParaFene05,@ParaFene06,@ParaFene07,@ParaFene08,@ParaFene09,@ParaFene10,@ParaFene11,@ParaFene12,@ParaFene13

   set the rect of window ONE of project ChHFSProj to rC(ParaFene01) -- 18,140,460,560

   set the resizable of window ONE of project ChHFSProj to ParaFene02 --  TRUE

   set the style of window ONE of project ChHFSProj to ParaFene03 -- standard

   set the autoBackSize of background ONE of window ONE of project ChHFSProj to ParaFene04 -- true

   set the autoResize of background ONE of window ONE of project ChHFSProj to ParaFene05 -- TRUE

   set the rect of fld one of window ONE of project ChHFSProj to rC(ParaFene06)

   define the anchorData of fld one of window ONE of project ChHFSProj to rC(ParaFene07) -- "Left,Top,Right,Botton"

   set the dontWrap of fld ONE of window ONE of project ChHFSProj to ParaFene08 -- FALSE

   set the lockText of fld ONE of window ONE of project ChHFSProj to ParaFene09 -- FALSE

   set the textFont of fld ONE of window ONE of project ChHFSProj to ParaFene10 -- Geneva

   set the textsize of fld ONE of window ONE of project ChHFSProj to ParaFene11 -- 14

   set the textstyle of fld ONE of window ONE of project ChHFSProj to ParaFene12 -- PLAIN

   set the textAlign of fld ONE of window ONE of project ChHFSProj to ParaFene13 -- LEFT

end ModiFenetre

The eC() and rC() function are for itemdelimiter conversion to avoid breaking up the items list. 

The CoerParams command is to coerce parameters, it had been discussed during the March 17th 2021 thread.

It all works very well, but to my naive surprise, just the first card of the project have the converted text properties in field one!

Is there a way to have a unique presentation for all cards of a single field in a project or do I have to go though all cards to convert them? 

My best regards and long live SuperCard!

André

----- 

As a picture worth a thousand words, here is a sample the the model project:

[Doug]

Background fields make a lot more sense than card fields in your case, I think.

However, because of the nature of SuperCard, each card's version of the background field is different. This allows the field to contain unique data for the card and unique formatting. So, yes, you have to set the formatting data (textFont, textSize, etc.) for each field. However, if you are only using the field to store data that will be presented on another card, perhaps in a different window, then the data can be copied and formatted by script.

I do this all the time. Supercard is a combination database and presentation program. As a database, background fields are exactly the same as a field in a record in a database. The record is a card in a window. The window is the database file. The project is the database. You don't actually have to look at the window. You can use it strictly as a database and access the information, and store the information, via script, from another window script, or the some other script (often the project script).

Not sure how much of that you already understood.

There are limits, of course, to how much information a field, how many fields, how many cards, how many windows, one can have in a single project. I usually find the limits by exceeding them. There are workarounds for the ingenious mind.

Doug, who has been advised to store his information in another program's files, but refuses because it just means one more potential failure as "upgrades" are done to the other program (app), or the OS.

[MARK LUCAS]

Hi André,

An important thing to understand about editable fields is that they have two fundamentally different types of properties...

Internally SuperCard buttons, fields, and graphics are called spots. Spot-level properties (such as rectangle, lockText, showLines, wideMargins, etc.) are unique attributes of (and are stored with) the spot record itself. Thus when you modify this type of attribute of a bkgnd field, the change affects all instances of the field.

Properties such as textFont, textSize, textFace (anything that can be applied as part of a style run) however are NOT actually spot-level attributes - instead they're attributes of (and are stored with) the TEXT in the field. They can be attached to all of the text or just a portion of it, but either way they're physically part of the field's CONTENTS (and not of the spot itself).

This distinction becomes vital when dealing with background fields. The text and style run information associated with card fields is stored along with the spot record (just like other spot attributes such as the rectangle), but the text and style info of bkgnd fields is actually stored with the card (NOT with the field itself).

Thus just as with the text itself setting text attributes of a bkgnd field on one card has no effect on the text-level attributes of instances of the field on other cards. If your object descriptor specifies a window and a bkgnd but NOT a card when you set such a property, then one of two things will happen:

- If the specified window is open and its current card DOES share the specified bkgnd then the change will be applied to the field contents attached to that card.

- If the specified window isn't open or the current card of the window DOES NOT share the specified bkgnd then the change is applied to the field contents on the first card of the specified bkgnd.

So if you want to tweak text-level attributes of bkgnd fields on multiple cards, you'll need to loop through them and do it separately for each card. Basically have two choices:

- You can specify the card number in the object descriptor, or

- You can open the card and use a local reference

If as in your case you plan to set multiple attributes on multiple cards, the second option is usually preferable because it will likely have much less overhead (otherwise each out-of-context reference will require unpacking the project, window, bkgnd, card, and field data, changing it, and then packing it back up again).

For example you might try something in this general form:

on setProps projDesc, wdNum, bgNum

  set cursor to busy

  lock screen

  lock messages

  open inv bg bgNum of wd wdNum of proj projDesc

  set the rect of this wd to "100,100,640,480"

  set the resizable of this wd to true

  set the style of this wd to scrolling

  set the autoresize of this bg to true

  set the autobacksize of this bg to true

  set the rect of fld 1 to "10,10,500,300"

  repeat with i = 1 to the num of cards of this bg

    open inv cd i of this bg

    set the textFont of fld 1 to Courier

    set the textSize of fld 1 to 18

    set the textStyle of fld 1 to plain

    set the textAlign of fld 1 to left

  end repeat

  save all

  compact

  close this wd

  unlock screen

  unlock messages

end setProps

If this is all just for cosmetic purposes then a simpler option would be to define one or more userProps of the field to hold the desired text attributes, and then add a closeCard handler that locks the screen and an openCard handler that applies the stored attributes each time a card of the bkgnd is opened. That way if you decide to change one of them, you won't have to loop through a million cards again and re-apply it.

Make sense?

-Mark

[André Tremblay]

Hello Doug, 

Le 06-févr.-2022 à 15:35:23, Doug <dde...@rogers.com> a écrit :

Background fields make a lot more sense than card fields in your case, I think.

Obviously it is a background field. 

However, because of the nature of SuperCard, each card's version of the background field is different. This allows the field to contain unique data for the card and unique formatting. So, yes, you have to set the formatting data (textFont, textSize, etc.) for each field. However, if you are only using the field to store data that will be presented on another card, perhaps in a different window, then the data can be copied and formatted by script.

Well, in this particular case the projects are solely to store text data. 

I don't have any issue to script the modification of all individual cards. It is just that, even with a six cores 32Gb MacPro with the data on the internal SSD, it will probably take days to go through the whole stuff! Not an invitation to do it too often!

I do this all the time. Supercard is a combination database and presentation program. As a database, background fields are exactly the same as a field in a record in a database. The record is a card in a window. The window is the database file. The project is the database. You don't actually have to look at the window. You can use it strictly as a database and access the information, and store the information, via script, from another window script, or the some other script (often the project script).

You have a good point, as I am trying to establish the right procedures to perform, read, write and search data into projects that are solely used as database. 

I am running into some type of issues that I wish to solve as the main SuperCard project can access data locally, but mostly over a network with APP, SMB and EPPC. The mix of local and network access doesn't go well, as it seems that whenever a database (project) is opened, it is grabbed by the local application. Even after being closed, the project will return FALSE when the cantmodify property is interrogated from another client application. Obviously a major drawback!

My preferred approach is to have a client application that do interrogate, over EPPC AppelEvents, a server application where the data projects are local. And to treat the requested data on the local client application. It's promising and fast even over the internet. 

Not sure how much of that you already understood.

I am trying my best to improve!

There are limits, of course, to how much information a field, how many fields, how many cards, how many windows, one can have in a single project. I usually find the limits by exceeding them. There are workarounds for the ingenious mind.

That's one the reason why the data are spread over several hundred projects, which average 2~6Mb each in size for several thousands of cards. 

Doug, who has been advised to store his information in another program's files, but refuses because it just means one more potential failure as "upgrades" are done to the other program (app), or the OS.

I have been considering moving the database engine to another program for a while, like SQL or SQLite, but SuperCard is doing such an incredible job at an incredible speed (according to my internal tests), why change?

I am just reading a message from Mark, it seems that I'll have to go through each cards individually, I'll let the computer do the work!

My best regards

André

[André Tremblay]

Hello Mark,

Le 06-févr.-2022 à 16:46:04, 'MARK LUCAS' via SuperCard Discussion <superca...@googlegroups.com> a écrit :

......

Properties such as textFont, textSize, textFace (anything that can be applied as part of a style run) however are NOT actually spot-level attributes - instead they're attributes of (and are stored with) the TEXT in the field. They can be attached to all of the text or just a portion of it, but either way they're physically part of the field's CONTENTS (and not of the spot itself).

Hey! What can you expect from an old time HyperCarder that is still unaware that all of this exist! 

I first taught that there was just one setting for all the cards of background fields! 

I've been looking for a "magic" checkbox saying “Same font for all cards” in the field info window!!!

So if you want to tweak text-level attributes of bkgnd fields on multiple cards, you'll need to loop through them and do it separately for each card. Basically have two choices:

 

.......

- You can open the card and use a local reference

If as in your case you plan to set multiple attributes on multiple cards, the second option is usually preferable because it will likely have much less overhead (otherwise each out-of-context reference will require unpacking the project, window, bkgnd, card, and field data, changing it, and then packing it back up again).

For example you might try something in this general form:

Thank you for the example! I'll integrate it right away in the loop and let the computer work overnight! 

The added benefit to go through all cards is the assurance that there isn't any corruption in the project!

If this is all just for cosmetic purposes then a simpler option would be to define one or more userProps of the field to hold the desired text attributes, and then add a closeCard handler that locks the screen and an openCard handler that applies the stored attributes each time a card of the bkgnd is opened. That way if you decide to change one of them, you won't have to loop through a million cards again and re-apply it.

I was also thinking to implement a user's property in the card, I suppose it would be more convenient to implement it at the background level and have the modification to be performed on opencard? 

Would window size, font type or size make any differences for the general performances?

Make sense?

Yes, question solved!

Thanks a bunch!

André

[MARK LUCAS]

On Feb 6, 2022, at 5:51 PM, André Tremblay <andre.t...@photographex.com> wrote:

I was also thinking to implement a user's property in the card, I suppose it would be more convenient to implement it at the background level and have the modification to be performed on opencard? 

The lodestar here is generally to minimize busywork and duplication of information when possible, so for your purposes saving the style info into one or more userprops of the bkgnd or of the field itself should be more or less functionally equivalent (depending on whether you might eventually want to add another field later, and whether you'd expect it to use the same style). Otherwise there'll be only one copy of the property saved in either case, and the overhead involved in accessing it shouldn't differ significantly.

Again based on your description (you've got up to a million instances of just one bkgnd field, and you only actually care about their text attributes on the rare occasions when you need to manually inspect the data contained in a few of them) the virtue of setting these attributes only upon display is that overall it's MUCH cheaper and faster than actually iterating over all the cards and changing the attributes stored for a million field instances just on the off chance that someday you might want to look at a handful of them (plus of course that you can later tweak any of the specified attributes with equally insignificant overhead).

Would window size, font type or size make any differences for the general performances?

If I understand your question then no. For this purpose any such differences are unlikely to rise noticeably above the 'background noise' that comes with running in a pre-emptive multitasking environment.

-Mark

[SdC du Saint-Claude]

Hello Mark, 

First of all, thank you for your ever presence to the SuperCard community! 

I wish to share a recurrent though that crossed my mind so many times during the last months while doing more intensive sessions of SuperTalk scripting; how wonderful the SuperCard environment is and how shameful the lack of support from Apple Corporation is toward its long time users as it is parting away from its legacy for “real intelligence”!

Le 06-févr.-2022 à 02:51:06, 'MARK LUCAS' via SuperCard Discussion <superca...@googlegroups.com> a écrit :

Could you be more specific about what you're trying to do, and what's happening (or not happening) that you didn't expect or don't like?