Rev’s libraries are not debuggable in that sense. If I recall, any stack name that begins with “rev” is considered a Livecode Library (which can be useful for people building their own libraries).
You can still however, use the new assert statement to build logging, or just simply use an answer dialog to view the contents of variables and such. You could also create your own logging script that writes to a low level file and include the handler name, the line of the script and any information you wanted to get from the script. Remo has a system of breakpoints that do not invoke a step debugger, but rather save the state of all variables at the time of the breakpoint so the developer can review them later. I haven’t heard anything about Remo lately though, so I am not sure if it is still a viable product. Bob On Feb 22, 2014, at 19:05 , David Epstein <dfepst...@comcast.net> wrote: > Thanks very much for the suggestions of other tools and the script that would > help me write my own. But before giving up completely on the basic table, > I'm trying to understand how it works (and, in the process, more about how > LiveCode works). > > Inspecting "the frontscripts", I discovered that the handlers governing basic > table fields are in the script of button "revTable" of group "revLibraries" > of stack "revLibrary." > > 1. Hoping to see table-editing in action, I set a checkpoint at the > beginning of the "on mouseUp" handler in that script. But clicking the field > did not cause execution to halt or the debugger to open. Are LiveCode's own > frontscripts not debuggable by the user? > > 2. It looks like if I am willing to edit LiveCode's own frontscript, I can > get the information I want. When I insert this statement > send "cellWasEdited pObject,txCell,tyCell,tNewText" to pObject > into the frontscript's "revWriteCellField" handler, I can handle a > "cellWasEdited" message in my table field's script. > > Doing this would mean my stack would not work on someone else's machine. I > also wonder whether fiddling with LiveCode's scripts is hazardous, or if > there are better ways of doing this. (I tried inserting my own closeField > handler in front, and having it pass closeField on to LC's frontscript. This > did not work. And some of the useful information is stored as script local > variables by LC's frontscript, which doesn't give me access to it in my own > script.) > > Any thoughts? > > David Epstein > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
