Hiding and un-hiding a Card & skipping when hidden

[deadparrotsoftware]

This is not as simple as I thought it would be.

I have a card in a stack that I want to be able to hide when the App starts, and hide or unhide the card when certain conditions are met.

When the card is hidden, I want navigation like next and back to skip the card.

Was looking for a simple solution, but as I discovered, even hiding the card gives errors -
for code such as: " set the visible of card 3 to FALSE "
I get errors like: " execution error at line n/a (Object: can't set this property) "

Did try several different methods of hiding.

Putting the card at the end, and just never showing it, doesn't really work for what we are doing.

So, looking for some suggestions.

Joe C.

[quailcreek]

Hi Joe,
Look up Mark and Marked in the dictionary. It's a property of a card that can be set to true or false. Then you can have your script look for this property to determine how to handle navigation to the card. Or you could set a custom property of the cards you want to control. Cards can't be hidden. Look up hide and scroll to the very bottom of the page.

[dunbarx]

Hi.

"Hide" can mean several things. As you learned, you cannot hide a card like you can hide a control. A card IS the window. If you had a stack with one card only, the only way to hide it is to close the stack or send it offscreen (a common trick, by the way).

Since you have several cards, you must skip it as required, just as I think you surmised. So in the stack script, you would place a preOpencard handler, and go "next" or "previous" if the card designator came up, and certain conditions were not met. I would hold those conditions in a custom property, unless they change on the fly, and you need to test them during each card change. Are you OK with that? As for initial conditions, like opening the stack itself, you can manage that in much the same way, or if that card is not the first card, you need do nothing at all.

Craig Newman

[deadparrotsoftware]

Thanks all for the suggestions. They are appreciated.

In non-hyperstack paradigms (such as Delphi) hiding windows is easy and common. It is a common practice to use hidden windows with controls (like a text box) to "store" lots of data inside the App (and avoid using resources or external files).
Things in livecode are awee bit...different.

It occurred to me that we could place the card in question in its own stack, as stacks can be hidden (or so my reading indicates).

Again, my thanks.

Joe C.
Chief Engineer

[dunbarx]

Hmmm.

That "hidden" again.

So do you really mean to make the card window disappear? Or just not be able to navigate to that card except under certain conditions? As i said, you can do either, in any of a handful of ways...

Craig

[Simon]

It is a common practice to use hidden windows with controls (like a text box) to "store" lots of data inside the App (and avoid using resources or external files).

Same as in liveCode. Though we do use external file (.txt, .db, .dat, etc.) if we need that information updated in a standalone. Now if it is your First card then you have to do some more work, if not, don't use keywords next and back but "go to cd "myCard"".

Simon

[jacque]

There's no need to store data in controls, it's typically done with custom properties. These are powerful and can store virtually any kind of data. The primary reason to store objects themselves in substacks is when you need a copy of the actual control for some reason, or when you need to reference an image for use as an icon, etc.

[deadparrotsoftware]

I agree custom controls are a ...more elegant approach. We tend to use controls as a quick and dirty approach, and for images, because access seems to be a wee bit faster that way (depending on what you are doing)

So I am going to play with controls on a card in a hidden sub stack.

Joe C

[jacque]

If you store text in fields, access time is much slower since accessing fields is one of the slowest things LC does. Custom properties are almost as fast as variables. Images are best stored in a substack or another card though, you're right about that, though disk access has been greatly optimized as well.

Do you know about custom properties yet? They're different from custom controls, which is a whole other animal.

[deadparrotsoftware]

I did not realize accessing fields in LC was so slow. In Xojo and Delphi, it is extremely fast. So we would store entire pages of text in text fields. It actually created less overhead than variables.

We also store text in labels on hidden screens.

Have not tried custom properties as yet - seemed a bit cumbersome for significant amounts of data like text. But that is better than making LC any slower than it sometimes appears to be now.

I do appreciate your insights on the issue.

Joe C.

[FourthWorld]

I did not realize accessing fields in LC was so slow. In Xojo and Delphi, it is extremely fast. So we would store entire pages of text in text fields. It actually created less overhead than variables.

It would be interesting to learn more about their underlying object structures to find out how their variables became more complex than a GUI control.

LC's text engine is pretty good compared to those of equivalent scope. It can buffer far larger amounts of text than even Microsoft Office apps without needing to page from disk, and the buffering provides a much smoother scrolling experience than you'll find in most office apps.

Do Xojo and Delphi provide the same scope of detailed paragraph-level formatting in a high-level property-driven way that works well on all platforms?

In most languages the simpler the structure the faster the access.

Given the number of steps any system will require to calculate and render font metrics, antialias them, calculate line wraps, adjust scrollbars, rebuild to local object buffer, reblit that back to the composite display buffer, etc., the number of machine instructions needed to work through the object structure to extract the text, do the works on the text, work it back into the object structure and then re-render it for every operation being done on the text is usually orders of magnitude more operations than just a couple of pointer dereferences from a string block.

[dunbarx]

When we say that field access is "slow", it might be useful to know what that means. I made two fields. One has ten chars, the other 1500 chars. I put this into a button:

Code: Select all

on mouseUp
   put the ticks into temp
   lock screen
   repeat 1000
      get fld 1
      put it into fld 1
   end repeat
 answer the ticks - temp

put the ticks into temp
 repeat 1000
      get fld 2
      put it into fld 2
   end repeat
   answer the ticks - temp
end mouseUp

Locking the screen is essential, of course, but there would never be a reason not to. Anyway. for field 1, 0 ticks, for field 2, 27 ticks.

But even this is a somewhat crazy exercise. Why would anyone perform such a task? Most processing is done out of the field itself, with only initial loading and final restoring, generally in one fell swoop. In other words, I cannot think of a scenario where field access, certainly slower than most LC activities, occurs in a continuous way as per the above example, and therefore really matters much.

Craig