Developing first on android

[Brian Milby]

 What about handlers?    Stacks already call preOpenStack and related handlers.    Adding handlers that get called automatically would leave it as script only but allow for post-load initialization.    I haven't looked to see what is already processed though.
  

  
  

  
  
>   
> On Aug 19, 2017 at 10:58 PM,  <Monte Goulding via use-livecode (mailto:use-livecode at lists.runrev.com)>  wrote:
>   
>   
>   
>  Hi Folks lcVCS was invented before script only stacks and for the most part script only stacks covers the use case much better. If you have a complicated stackFile then no matter what text representation we make of it you would get lost dealing with merge conflicts and diffs. If you don’t believe me try looking at an Xcode storyboard merge conflict… it’s no fun. You really are better off just being careful to avoid working on ui stuff on multiple branches. If you have a trivial UI then you can generate it on the fly as we do with some stacks in the IDE. If you have something a little bit too complicated for hand coding generation on the fly then you could use something like the scriptonlyUI library I experimented with one rainy day https://github.com/montegoulding/scriptonlyui . Anything more complicated is just as well off staying a binary file and using script only behaviors for scripts. Having said that there _are_ a couple of stack properties that we could add to script only stacks to make things work better and I don’t think it would be all that tricky to add something YAML like that the engine reads between the `script “”` header and the stack script. The properties that I would add are behavior and stackFiles so your script only stack would look like this: script “StackName” --- behavior: stack “ParentBehavior” stackFiles: - ParentBehavior: some/path.livecodescript --- command MyHandler -- code end MyHandler There could be some other properties that would be helpful but I think these are the critical ones causing issues for behavior hierarchies which are lost when saving so you need to script them. Perhaps even stackFiles isn’t that necessary as the stackFiles could be set on a binary stack elsewhere or the stack could be in a location the engine would find it. We would probably only want to add properties that we feel are causing issues which behavior definitely is. The less you add the less chance of a merge conflict on some change you didn’t intent. Of course once you add _any_ properties it’s suddenly _not_ a script only stack so… BTW if we only wanted to add behavior and only stack behaviors at that it might be nice to just include that in the header: script “StackName” with behavior “ParentBehavior” command MyHandler — code end MyHandler I actually really like this option as it’s in keeping with the original faceless script object concept. Cheers Monte _______________________________________________ use-livecode mailing list use-livecode at lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode  
>
>