The debugger has always had a method Debug.write that can be used to output to the debugger console. It takes any number of arguments and outputs them, separated by spaces. It uses the Debug.__String method to present objects, which makes them 'inspectable' in the output window (you can click on them to invoke Debug.inspect on the object).
In 3.2 (and perhaps earlier) there is a new method, Debug.format, that acts more like printf. It takes a 'control' string, and any number of arguments and formats the arguments according to the format directives in the control string. For the most part it supports the same directives as printf, but there is an additional one, %w, which outputs the argument as if it were printed by Debug.write, thus making it inspectable. [In the Legal's branch, objects that are formatted by %s are also inspectable, but their presentation is as if they were printed by toString.] Debug.warn and Debug.error take arguments like Debug.format and create warnings or error messages on the debugger console. They are labeled with a tag (WARNING: or ERROR:) and presented in orange or red. They have the additional feature that if backtracing is enabled, they capture a backtrace, which can be seen by inspecting (clicking on) the message. In recent weeks I have had several bug reports that Debug.warn and Debug.error do not work. Apparently this is because the caller expected them to be like Debug.write and simply take a list of arguments that are output separated by spaces. What they see is only their first argument being printed (because it is interpreted as a control string with no format directives). It occurred to me today that I could have them check for the case of multiple arguments with no format controls in the first argument and operate in 'Debug.write compatibility mode' if that is the case. Would this be useful? Too complex to document? Are there pitfalls? Is there a use case where ignoring the extra arguments is really what is desired? Your comments solicited. _______________________________________________ Laszlo-dev mailing list [email protected] http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
