Quoting between substacks

[kresten]

I have previously developed a function to parse in the content of users accumulating daycards of my multidimensioned diary application ”Phenomenalog” where the results from the parsings where sent to html files in an external folder.
I have now decided to develop the application in such a way, that the parsingsresult shall be acumulated on cards in a new substack ”Parsings” with one line field for the searching-title and a crolling field for the occasions.
My problem is that I miss a way to store the parsing-results ( as a list ?) without leaving the daycard stack, and only when completed turn to the new card in the parsings stack and paste the resulting list in the occasions field there.

[FourthWorld]

You can set any property of any object in any stack, even if it's not been explicitly opened.

So this will work:

Code: Select all

set the text of fld "SomeField" of cd "SomeCard" of stack "SomeStack" to tVar

[kresten]

Thank you for the reply. But I can see that the title of my topic was misleading .
I think the best I can do is to quote the whole original handler, with its reference to an external folder.
Which editing is necessary if the result instead shall accumulate on a new card in a sub stack "Parsings" with the description of when and what was searched in a one line field "searching" and the results in a scrolling field "Occasions".
Actually I have a parallel handler "Glyphparse" more complex, because it refers to pictogram-characters in 12 application-specific fonts. But if we solve the re-editing of the Phenoparse handler I could hope to apply the knowledge to the glyphparse handler,

Code: Select all

   ------------------
on phenoparse
   global phenodate,destination,cue
   ask "Which word shall be searched?"
   if it is empty then
      exit phenoparse
   else
      put it into cue
   end if
   ask "How many lines before ?" with "0"
   if it is cancel then
      exit phenoparse
   end if
   put it into avant
   ask "How many lines after ?" with "0"
   if it is cancel then
      exit phenoparse
   end if
   put it into apres
   put "Parsed for" && cue && phenodate & ".html" into filename
   put the effective filename of this stack into destination
   set the itemdelimiter to "/"
   delete last item of destination
   delete last item of destination
   delete last item of destination
   open file destination &"/"& parsings &"/"& filename
   lock screen
   set lockmessages to true
   go first card of stack "Phenomenalog"
   find string cue in field "TextField"
   if the result is "not found" then
      answer "Cannot find this word"
      exit phenoparse
   else
      put short name of this card && the foundchunk into start
      put short name of this card into hitcard
      write "<p>" & short name of this card & "</p>" to file destination & "/" & parsings  &"/"& filename
      write the htmltext of line (word 2 of the foundline) - avant to (word 2 of the foundline) + apres of field "Textfield" to file destination & "/" & parsings  &"/"& filename
   end if
   repeat
      set cursor to busy
      find string cue in field "TextField"
      if short name of this card && the foundchunk is start then
         exit repeat
      end if
      if short name of this card is not hitcard then
         put short name of this card into hitcard
         write "<p> ----------------------</p>" to file destination  &"/"&  parsings  &"/"& filename
         write "<p>" & short name of this card & "</p>" to file destination & "/" & parsings &"/"& filename
      end if
      write the htmltext of line (word 2 of the foundline) - avant to (word 2 of the foundline) + apres of field "Textfield" to file destination  & "/" & parsings & "/" & filename
   end repeat
   --  save file filename
   close file destination & "/" & parsings  & "/" & filename
   go last card
   put return & phenodate && the time && "Parsed:" && cue after field "TextField"
   go stack "Parseviewer"
   show stack "Parseviewer"
   set the htmltext of field "Showfield" to URL ("file:"& destination  & "/" & parsings  & "/" & filename)
end phenoparse 

[dunbarx]

Hi.

Not exactly sure what the question is.

Richard spoke about being able to set a property anywhere on a remote stack (or subStack). You can also just as easily load data into remote fields. Is that what you are asking about?

All this without ever navigating anywhere, of course.

Craig

[dunbarx]

Richard.

You can set any property of any object in any stack, even if it's not been explicitly opened.

In a new session, a stack has to be opened, though it can then be closed, for another stack to access its controls and properties. And if the destroyStack property of the target stack is set, and that stack is closed, it is not accessible from another stack.

Craig

[FourthWorld]

Richard.

You can set any property of any object in any stack, even if it's not been explicitly opened.

In a new session, a stack has to be opened, though it can then be closed, for another stack to access its controls and properties. And if the destroyStack property of the target stack is set, and that stack is closed, it is not accessible from another stack.

Well, with substacks we can safely assume the stack file they belong to is open if we're addressing the substack from that stack file's mainstack.

But even in separate stack files it still works. I have no reason to mislead you. When I'm unsure of something I'll include qualifiers, like "should" or "might" or some such. In the rare case when I write without qualifiers, it's because it's something I know from years of first-hand experience to be true.

Let's test it:

-- Create the test stack files:
1. Create a new stack, and name it "aaa".
2. Save the stack to the Desktop, so its stackfile is named "aaa.livecode".
3. Create another new stack, this one named "bbb"
4. Put a button on the cd of stack "bbb" with this script:

Code: Select all

on mouseup
   -- Get the file name to stack "aaa":
   put the filename of this stack into tStackFile
   replace "/bbb.livecode" with "/aaa.livecode" in tStackFile
   --
   -- Set a property without opening it:
   set the rect of stack tStackFile to 100,100,1000,1000
   -- Save the change:
   save stack tStackFile
end mouseup

5. Save stack "bbb"
6. Quit LiveCode, so we can be assured nothing is remaining in memory.
-- Run the test:
7. Re-launch LC.
8. Open only stack "bbb.livecode"
9. Click the button.
10. Quit LC, so we've have an entire new session in which we've never opened "aaa".
-- Evaluate the result of the test:
11. Re-launch LC
12. Open stack "aaa.livecode"
13. In the Message Box, run:

Code: Select all

put the rect of stack "aaa"

What do you get?

[dunbarx]

Richard, first off do you think I imagine you are trying to mislead me? How long have I known you? Wait, don't tell me.

I looked at the handler you posted, and stopped. Let me propose a much simpler test.

Make two stacks, "aaa" and "bbb". Put a field on "bbb" and a button with this in its script on "aaa":

Code: Select all

on mouseUp
   put random(999) into fld 1 of stack "aaa"
end mouseUp

Click on the button, you get an integer in the field on "bbb".

Save everything. Quit LC.

Now open "aaa" and click on the button. LC cannot find stack "bbb", because it is just sitting on the desktop. But if you open "bbb" (and feel free to then close it) clicking the button in "aaa" runs without issue, because "bbb", though closed, (unless the "destroyStack" property is set) is still in LC's memory. If you open it again, you will find a different integer in the field.

So "bbb" is "open" even if it is, er, closed, because it was open at least once in the current session. In that condition, closed and sitting on the desktop, it has the value in its field changed every time we click on the button in "aaa".

But if it was never opened in the current session, LC has no idea it even exists.

Craig

[FourthWorld]

Craig, your test omits a key element from mine in its search for simplicity, something that's easy to overlook from a HyperCard background but can be very powerful - you wrote:

But if it was never opened in the current session, LC has no idea it even exists.

It depends on how you refer to the stack.

Look at the first part of my script.

We can refer to stacks by their short name only when the engine has some means of knowing how a stack object name relates to a stack file. In LC this often means we need to either have opened the stack file, or have it listed among the entries in a stackfiles property in one of our open stacks.

But we can just as easily refer to mainstacks by their file path. E.g., this:

stack "aaa"

...is the same as this:

stack "/home/rg/Desktop/aaa.livecode"

It's certainly more convenient to use the short name, and HC made it easy to do that with a combination of stack files limited to a single stack, in which the name was never different from the file name, and the Home stack had an extensible list of directory paths to look for things in, the Search Paths.

LC has no Search Paths, which aren't really useful for a more standalone-centric tool anyway.

But LC does allow the full file name of the stack file to be used synonymously with the short name of the mainstack, with the added advantage that if the mainstack has never been opened in the current session the full-path form will do the trick.

So as long as the object you want to modify has a disk location that's knowable (and how often would one want to modify random unknown files?), the rule stands:

You can set any property of any object in any stack, even if it's not been explicitly opened.

[bwmilby]

Why not just accumulate the data in a variable instead? That will be much faster than using a file and faster than using a field too. Instead of all of the write statements you could just put xxx after tData.

[[-hh]]

You can set any property of any object in any stack, even if it's not been explicitly opened.

You didn't try. Did you?

Make a new stack (="Untitled 1") with one field and save it as </path/to/file/a.livecode>.
Then restart LC and make a new stack (="Untitled 1") with a button. Button's script:

Code: Select all

on mouseUp
  put 1 into fld 1 of card 1 of stack </path/to/file/a.livecode>
end mouseUp

... Your rule doesn't apply for that scenario here.

[dunbarx]

Richard. And Hermann, too, I think.

So I made two new stacks, "aaa' and "bbb". Saved both. In a button on "aaa":

Code: Select all

on mouseUp
   put random(999) into fld 1 of stack "/Users/craignewman/Desktop/bbb.livecode"
   answer fld 1 of stack  "/Users/craignewman/Desktop/bbb.livecode"
   save stack "/Users/craignewman/Desktop/bbb.livecode"
end mouseUp

In "bbb" there is just a field.

I quit LC and opened "aaa" from the desktop. Clicked the button, got an integer. Quit LC. Re-open "bbb" from the desktop. That integer was in the field.

Thank you for the explanation, that I sort of once knew, but never pay any attention to. And the HC background thing is pertinent. I do not do much pathname stuff in my LC world, apart from reading and writing to external files, so that sort of thing is not on my radar.

Craig

[dunbarx]

This may be a useful lesson, (it was for me) and might merit its own thread.

Craig

[Klaus]

...
Your rule doesn't apply for that scenario here.

Well, the rule demands a developer who is at least a little smart!

That means a developer who does not use/save two stacks with the same name,
where using "Untitled N" as their name is the peak of un-smart-ness in my opinion.

[bwmilby]

But you can get two stacks in memory with the same short name if you really want to (but not by opening from disk)...

[Klaus]

Who would want so?