Navigating from once card to another problem

[glenn9]

Hi everyone,

whilst typing in a field of card A my text will, depending on what is typed, trigger showing a card B.
I've got the code working for this along the lines of:

Code: Select all

on rawkeyup
... triggering condition...
go to card B

so far so good...
but when card B shows I still want to continue typing in card A, so I'd almost like a function in card B along the lines of...

Code: Select all

on 'somefunction'
go to field 1 of card A (and stay there!)

I've tried the above but the problem I've got is that each time I type in card A, I trigger a rawkeyup and therefore repeatedly go to card B - I just want to have gone to card B once - its a much smaller card than card A so I can refer to the information on card B whilst I'm typing in card A.

Not sure how to achieve this by script... grateful for any tips!

Kind regards,

Glenn

[richmond62]

its a much smaller card than card A

I'm lost here . . .

1. ALL cards in a stack are the same size.

2. How can you refer to one card while typing in the field of another card?

3. Why do I feel that what you are describing (if I understand it correctly) might not be better
with a stack "A" and a substack "B"?

[dunbarx]

This can be done. I think Richmond's point was that you can only view one card at a time within a single stack.

So try this. Make a new stack with two cards. Put a field in card 1, and anything identifying on card 2. In the stack script:

Code: Select all

on keyDown tKey
   put tKey after fld 1 of cd 1
   if tKey = "x" then go cd 2
   if tKey = "y" then go cd 1
end keyDown

Start typing while viewing card 1. It does not matter if the field has focus or not. When you type an "X", you will find yourself on card 2. If you keep typing, you will continue to append to the field on card 1. If you type a "Y", you will go back to cd 1. You can seesaw back and forth all day if you want to.

Craig

[richmond62]

Richmond's point was twofold:

1. You can only see one card in a stack at one time.

2. You cannot have different sized cards in one stack.

[dunbarx]

Richmond.

I did not really see the "much smaller" portion of the OP's post. You are correct in that either another stack (or resize a single stack based on which card is in front) is required.

So, Glenn, how important are the issues here? We already see that you can do the typing thing without a problem. How do you want to handle the card size thing? Richmond implied that the way forward was to be able to have one or both card windows open as you wish, at whatever size you wish, but with two separate stacks. That works fine, and I see no downside. But you could resize a single stack if you want to.

Craig

[dunbarx]

Glenn.

Know that if you do choose to use two separate stacks, a slight modification to the stack script in stack 1 is required:

Code: Select all

on keyDown tKey
   put tKey after fld 1 of cd 1 of stack "untitled 1"
   if tKey = "x" then go cd 1 of stack "untitled 2"
   if tKey = "y" then go cd 1 of stack "untitled 1"
end keyDown

and the script of stack 1 has to be made into a back script:

Code: Select all

insert script of stack "untitled 1" into back

Not a big deal.

Craig

[dunbarx]

It occurs to me that placing a keydown handler as a backScript is fraught with peril, unless you limit such a beast to the pertinent stacks;

Code: Select all

on keyDown tKey
   if the short name of this stack is  not"untitled 1" and the short name of this stack is  not "untitled 2" then pass keydown
   else
      put tKey after fld 1 of cd 1 of stack "untitled 1"
      if tKey = "x" then go cd 1 of stack "untitled 2"
      if tKey = "y" then go cd 1 of stack "untitled 1"
   end if
end keyDown

This is why testing is considered by some to be an important component of stack design.

Craig

[FourthWorld]

If you:

- place fld 1 of card A in a group
- set that field's sharedText to true
- set the group's sharedBehavior to true
- place the group on all cards

...then you can type into it from any card without the need to fiddle with multiple stacks, window focus, etc.

[dunbarx]

Richard exploits a terrific feature of grouped sharedText fields; you are essentially typing into all such fields on all cards at once.

But does the OP want to see that " original" field when he moves to the "much smaller" card window? We do not know what that card looks like, that issue not yet dealt with. As for placing them on "all" cards, I am sure you meant only on cards where typing will continue, but I got the impression that when on the other smaller card, that field was neither needed nor wanted.

But if two stacks are required to manage different card sizes and/or styles, the backScript method, however kludgey, may be preferable.

Anyway, Glenn?

Craig

[FourthWorld]

Richard exploits a terrific feature of grouped sharedText fields; you are essentially typing into all such fields on all cards at once.

But does the OP want to see that " original" field when he moves to the "much smaller" card window?

Yes, this is based on a guess about the design goals. Given the frustration of typing something that can't be seen, I'm assuming the OP doesn't actually want to do that. Multi-window options seem based on the same assumption.

Many threads would benefit from a screen shot or deeper explanation of what's desired. This is one of them.

[SparkOut]

Sounds like an info sheet just as a reference pane while working on the original card. Maybe a palette stack, or perhaps a bit like stam's popover widget viewtopic.php?f=7&t=34834&start=30#p197818

[glenn9]

Apologies, I'll try and insert an image of what I'm trying to achieve, just trying to figure out how to do this inset an image into the thread...

[dunbarx]

Hi.

Attach your (zipped) image file using the "attachments" tab below the text field. This opens a button named "Add Files". You can opt to place it in-line once you have it.

Craig

[SparkOut]

Images don't need to be zipped (just not overly large)

[dunbarx]

Sparkout.

True? I thought all files had to be.

Craig