Page 1 of 1

"clickObject" and perhaps a redirect property

Posted: Sat Oct 19, 2013 11:21 am
by srdlrtr
Sometimes, especially on projects with a large amount of data and frequent script changes, I like to separate the data in one file and the scripts in another (among other reasons, so I can save script changes frequently without waiting for the data) while still retaining the flexibility to add scripted buttons and fields on the data stack.

One good way I've found is to mirror the buttons and fields on a script card in a separate stack in a separate file, and replace each script handler in the original data stack with a script that calls the mirror in the script stack. For reasons not clear to me, the "call" command, which is supposed to retain the original context, doesn't preserve the original value of "the target" (which I think it should, but life is often like that).

For fields, I can get the originally-clicked object name with the clickField function (and several others). But for buttons and other non-field objects, there appears to be no direct equivalent. What I'd like to see added, therefore, is a function "clickobject" that would parallel clickField or clickStack, but would report any first object that received the initial mouseclick. Obviously, changing "the target" is out because it would break an unknown number of stacks.

From a more global perspective, eventually it would be nice if we had a redirect property for all objects --sort of like a chute that would direct all messages received by the object to a different specified object and then up the message path from there. I gather there are some undocumented features that might be used for this but not efficiently -- whereas what I would want is a true documented feature.

Thanks for reading this far, and any thoughts or comments.

Re: "clickObject" and perhaps a redirect property

Posted: Sat Oct 19, 2013 11:36 am
by Klaus
Hi srdlrtr,

not sure what you are after, but maybe this article will help you with your problem: ... _path.html

But I have to confess that I never had problems with "the target" in the last 13 years! 8)
You know about "behaviors"? I use them a LOT, great stuff!

What did you script (and where) so far?
Maybe we can finetune your script(s).

Ah, and welcome to the forum! :D



Re: "clickObject" and perhaps a redirect property

Posted: Sun Oct 20, 2013 1:23 am
by srdlrtr
Thanks. That's an excellent solution -- and one that's retrospectively obvious. It also deals with my problem with "the target" -- a behavior script does show properly whether the original activation came from the child or the parent.

And you're also right that I don't think about behaviors when I should. I guess I haven't changed my habits enough as Rev/LC has evolved. In my small defense, they're given rather cursory treatment in the user guide, and I had mentally consigned them to interface issues rather than code. Gaskin's description of them as individual backscripts is much better.

The specific application in this case is an integrated set of programs I use for doing the paperwork for my wife's therapy practice. Because of the complexity of healthcare laws, privacy laws, interfaces with insurance billing systems, etc, it's in the tens of thousands of lines of code spread over a dozen stacks -- and there's rarely a month that I don't need to make a change to the routines and/or the structure of the database. For example, last month the HIPAA rules changed slightly for both the "Notice of Privacy Practices" form and for the privacy rules for communicating with clients. The routine which sends out email reminders now has to track which clients have specifically ok'd using email systems such as gmail because there is a possibility someone at Google could read the messages at their hub -- and the privacy right belongs to the client. That, in turn meant generating new disclosure and release forms, and tracking which clients had received them and filled them out.

Because LC only allows one behavior per child, I guess I'd still like to see a "true" version of "call" (presumably with a different name) that would act more like behaviors and keep the entire context, along with a documented way to reroute all received messages.

Re: "clickObject" and perhaps a redirect property

Posted: Sun Oct 20, 2013 2:31 am
by Simon
Hi srdlrtr,
Because LC only allows one behavior per child
Actually liveCode now has "chained behaviors" so you can have your "behavior" button have a behavior. Not sure that actually helps you in your case.

I have to say I'm really impressed on hearing you are using liveCode in an HIPAA environment, I think that's really cool. I've stayed away from medical records because of the security required, yet you say liveCode has all necessary to handle it. Maybe I've read too much into HIPAA security.

I don't know about others but I think your app and use of liveCode would make a great newsletter article.


Re: "clickObject" and perhaps a redirect property

Posted: Sun Oct 20, 2013 3:19 am
by srdlrtr
Thanks for the heads up on the chained behaviors. Apparently, Gaskin's article pre-dates that (it says "Also, behaviors cannot be nested; that is, even if you assign a behavior to a behavior button, that second behavior won't be invoked."). I'll have to experiment with that and see how I can put it to good use.

As far as I know, LC doesn't by itself have HIPAA-compliant privacy features. But I keep all the data on a TrueCrypt encrypted disk (with regular backups, of course). I'm astounded that we still read reports of people in the medical field losing laptops with client/patient data that isn't encrypted when it's such a small effort to do that.

Most of my code is hardly a good example -- I dislike the Rev/LC naming conventions and don't often clean up what works since there are no users to support except me. Long ago and far away when I was a mainframe programmer, it made sense to do that (since life-cycle support costs far outweighed the original coding), but I'm not sure it would in this cse.

However, even in the latest version, I still crash LC regularly and it doesn't usually crash gracefully (which I why I want to be able to save easily). BTW, if there's been an update that lets me determine if a stack is dirty (i.e, changed from when it was read), I could really use that.

But I do have some feature suggestions for anyone else who does this. For one, I included a feature that replaces the data on printing with 0's for numbers and asterisks for alphas to be able to check processing with actual data but show someone the resulting forms without revealing that data. And for filling out various forms and pages on insurance company websites, I have LC generate the data and put it on the clipboard, then have AutoHotkey actually type it in (AHK can also read screen objects, so I can have it check the form is still what it was last week with the same keystrokes needed to enter the data, which isn't a given).

Again, thanks for the help and suggestions.

Re: "clickObject" and perhaps a redirect property

Posted: Sun Oct 20, 2013 5:24 pm
by FourthWorld
srdlrtr wrote:Apparently, Gaskin's article pre-dates that (it says "Also, behaviors cannot be nested; that is, even if you assign a behavior to a behavior button, that second behavior won't be invoked.").
Thanks for the reminder - I've just updated that article to reflect current features.