source: trunk/doc/src/scripting/qtscriptdebugger-manual.qdoc@ 564

Last change on this file since 564 was 561, checked in by Dmitry A. Kuminov, 15 years ago

trunk: Merged in qt 4.6.1 sources.

  • Property svn:eol-style set to native
File size: 14.8 KB
Line 
1/****************************************************************************
2**
3** Copyright (C) 2009 Nokia Corporation and/or its subsidiary(-ies).
4** All rights reserved.
5** Contact: Nokia Corporation ([email protected])
6**
7** This file is part of the documentation of the Qt Toolkit.
8**
9** $QT_BEGIN_LICENSE:LGPL$
10** Commercial Usage
11** Licensees holding valid Qt Commercial licenses may use this file in
12** accordance with the Qt Commercial License Agreement provided with the
13** Software or, alternatively, in accordance with the terms contained in
14** a written agreement between you and Nokia.
15**
16** GNU Lesser General Public License Usage
17** Alternatively, this file may be used under the terms of the GNU Lesser
18** General Public License version 2.1 as published by the Free Software
19** Foundation and appearing in the file LICENSE.LGPL included in the
20** packaging of this file. Please review the following information to
21** ensure the GNU Lesser General Public License version 2.1 requirements
22** will be met: http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html.
23**
24** In addition, as a special exception, Nokia gives you certain additional
25** rights. These rights are described in the Nokia Qt LGPL Exception
26** version 1.1, included in the file LGPL_EXCEPTION.txt in this package.
27**
28** GNU General Public License Usage
29** Alternatively, this file may be used under the terms of the GNU
30** General Public License version 3.0 as published by the Free Software
31** Foundation and appearing in the file LICENSE.GPL included in the
32** packaging of this file. Please review the following information to
33** ensure the GNU General Public License version 3.0 requirements will be
34** met: http://www.gnu.org/copyleft/gpl.html.
35**
36** If you have questions regarding the use of this file, please contact
37** Nokia at [email protected].
38** $QT_END_LICENSE$
39**
40****************************************************************************/
41
42/*!
43 \page qtscriptdebugger-manual.html
44 \title Qt Script Debugger Manual
45 \brief A manual describing how to use the Qt Script debugger.
46
47 The Qt Script debugger is a tool for debugging script execution in
48 Qt applications that use Qt Script. Application developers can embed
49 the debugger into their application through the
50 QScriptEngineDebugger class. This manual describes how to use the
51 debugger. We assume that the reader is somewhat familiar with
52 general debugging concepts and existing debugging tools.
53
54 We assume that the debugger has been integrated into the application
55 through the QScriptEngineDebugger::standardWindow()
56 function, which provides the standard debugger configuration.
57
58 \tableofcontents
59
60 \section1 Getting Started
61
62 The following image shows the debugger as created with
63 \l{QScriptEngineDebugger::}{standardWindow()}:
64
65 \image qtscript-debugger.png Running a script under the Qt Script debugger.
66
67 The debugger will start, i.e., take control over the script's
68 execution when any of these conditions are met:
69
70 \list
71 \o The \c{debugger} statement is encountered in the script.
72 \o Clicking the \gui Interrupt menu item from the \gui Debug
73 menu in the main window.
74 \o A breakpoint is reached.
75 \o An uncaught script exception is thrown.
76 \endlist
77
78 Once the debugger is started, the execution state can be inspected,
79 e.g., the value of variables can be queried and the current program
80 stack shown. New breakpoints can be set.
81
82 The debugger will resume, i.e., give the control back to the script
83 engine, when the user clicks \gui Continue menu item from the \gui
84 Debug menu. It will be invoked again if one of the conditions
85 described in the list above is met.
86
87 \section1 Overview of Debugger Components
88
89 The debugger's functionality is divided into a series of components,
90 each being a widget that can be shown in the main window of the
91 debugger. The following table describes each component and how they
92 relate to each other.
93
94 \table
95 \header
96 \o Component
97 \o Description
98 \row
99 \o Console Widget
100 \o The console widget provides a command-line interface to the
101 debugger's functionality, and also serves as an interactive script
102 interpreter. The set of commands and their syntax is inspired by
103 GDB, the GNU Debugger. Commands and script variables are
104 auto-completed through the TAB key.
105
106 Any console command that causes a change in the debugger or debugger
107 target's state will immediately be reflected in the other debugger
108 components (e.g. breakpoints or local variables changed).
109
110 The console provides a simple and powerful way of manipulating the
111 script environment. For example, typing "x" and hitting enter will
112 evaluate "x" in the current stack frame and display the result.
113 Typing "x = 123" will assign the value 123 to the variable \c{x} in
114 the current scope (or create a global variable \c{x} if there isn't
115 one -- scripts evaluated through the console can have arbitrary side
116 effects, so be careful).
117
118 \row
119 \o Stack Widget
120 \o The stack widget shows a backtrace of the script execution state.
121 Each row represents one frame in the stack. A row contains the
122 frame index (0 being the inner-most frame), the name of the script function,
123 and the location (file name and line number). To select a particular
124 stack frame to inspect, click on its row.
125
126 \row
127 \o Locals Widget
128 \o The locals widget shows the variables that are local to the
129 currently selected stack frame; that is, the properties of the
130 objects in the scope chain and the \c{this}-object. Objects can be
131 expanded, so that their properties can be examined, recursively.
132 Properties whose value has changed are shown in bold font.
133
134 Properties that are not read-only can be edited. Double-click on the
135 value and type in the new value; the value can be an arbitrary
136 expression. The expression will be evaluated in the associated stack
137 frame. While typing, you can press the TAB key to get possible
138 completions for the expression.
139
140 \row
141 \o Code Widget
142 \o The code widget shows the code of the currently selected script.
143 The widget displays an arrow in the left margin, marking the
144 code line that is being executed.
145 Clicking in the margin of a line will cause a breakpoint to be
146 toggled at that line. A breakpoint has to be set on a line that
147 contains an actual statement in order to be useful.When an uncaught script exception occurs, the
148 offending line will be shown with a red background.
149
150 The code widget is read-only; it cannot currently be used to edit
151 and (re)evaluate scripts. This is however possible from the
152 command-line interface, see \l{Console Command Reference}.
153
154 \row
155 \o Scripts Widget
156
157 \o The scripts widget shows the scripts that are currently loaded in
158 the script engine. Clicking on a script will cause its code to be
159 shown in the code widget. When a script is no longer referenced by
160 the debugger target it is removed from the scripts widget. Code
161 evaluated through QScriptEngine::evaluate() without a name specified, will be
162 displayed in the widget as Anonymous.
163
164 \row
165 \o Breakpoints Widget
166
167 \o The breakpoints widget shows all the breakpoints that are set. A
168 breakpoint can be disabled or enabled by clicking the checkbox next
169 to the breakpoint's ID (the ID is provided so that the breakpoint
170 can be manipulated through the console widget as well).
171
172 A condition can be associated with the breakpoint; the condition can
173 be an arbitrary expression that should evaluate to true or
174 false. The breakpoint will only be triggered when its location is
175 reached \bold{and} the condition evaluates to true.
176
177 Similarly, if the breakpoint's ignore-count is set to N, the
178 breakpoint will be ignored the next N times it is hit.
179
180 A new breakpoint can be set by clicking the New Breakpoint button
181 and typing in a location of the form <filename>\bold{:}<linenumber>.
182 The breakpoint location can refer to an already loaded script, or
183 one that has not been loaded yet.
184
185 \row
186 \o Debug Output Widget
187 \o The debug output widget shows messages generated by the print()
188 script function. Scripts can use the special variables \c{__FILE__}
189 and \c{__LINE__} to include the current location information in the
190 messages.
191
192 \row
193 \o Error Log Widget
194 \o The error log widget shows error messages that have been generated.
195 All uncaught exceptions that occur in the engine will appear here.
196
197 \endtable
198
199 \section2 Resuming Script Evaluation
200
201 Script evaluation can be resumed in one of the following ways:
202
203 \list
204 \o \bold{Continue}: Evaluation will resume normally.
205 \o \bold{Step Into}: Evaluation will resume until the next statement is reached.
206 \o \bold{Step Over}: Evaluation will resume until the next statement is reached;
207 but if the current statement is a function call, the debugger
208 will treat it as a single statement.
209 \o \bold{Step Out}: Evaluation will resume until the current function exits and
210 the next statement is reached.
211 \o \bold{Run to Cursor}: Run until the statement at the cursor is reached.
212 \o \bold{Run to New Script}: Run until the first statement of a new script is reached.
213 \endlist
214
215 In any case, script evaluation can also be stopped due to either of the
216 following reasons:
217
218 \list
219 \o A \c{debugger} statement is encountered.
220 \o A breakpoint is hit.
221 \o An uncaught script exception occurs.
222 \endlist
223
224 \section2 Resuming After an Uncaught Exception
225
226 When an uncaught script exception occurs, it is not possible to
227 continue evaluating the current function normally. However, you can
228 use the console command \bold{return} to catch the exception and
229 return a value to the calling function.
230
231 \section1 Console Command Reference
232
233 Note that you can also get help on the available commands by typing
234 ".help" in the console.
235
236 \section2 Breakpoint-related Commands
237
238 Break points is set
239
240 \section3 break <location>
241
242 Sets a breakpoint at a given code line.
243
244 \code
245 .break foo.qs:123
246 \endcode
247
248 This command sets a breakpoint at \c{foo.qs}, line 123.
249
250 \code
251 .break 123
252 \endcode
253
254 This command sets a breakpoint at line 123 in the current script; the current script
255 is the script associated with the current stack frame.
256
257 Each breakpoint has a unique identifier (an integer) associated with it.
258 This identifier is needed by other breakpoint-related commands.
259
260 \section3 clear <location>
261
262 \code
263 .clear foo.qs:123
264 \endcode
265
266 clears (deletes) the breakpoint at \c{foo.qs}, line 123.
267
268 \code
269 clear 123
270 \endcode
271
272 clears (deletes) the breakpoint at line 123 in the current script;
273 the current script is the script associated with the current stack
274 frame.
275
276 \section3 condition <breakpoint-id> <expression>
277
278 Sets a condition for a breakpoint.
279
280 \code
281 .condition 1 i > 42
282 \endcode
283
284 specifies that breakpoint 1 should only be triggered if the variable \c{i}
285 is greater than 42.
286
287 The expression can be an arbitrary one, i.e. it can have
288 side-effects. It can be any valid QScript conditional
289 expression.
290
291 \section3 delete <breakpoint-id>
292
293 Deletes a breakpoint, i.e., removes it from the current debugging
294 session.
295
296 \section3 disable <breakpoint-id>
297
298 Disables a breakpoint. The breakpoint will continue to exist, but
299 will not stop program execution.
300
301 \section3 enable <breakpoint-id>
302
303 Enables a breakpoint. Breakpoints are enabled by default, so you
304 only need to use this command if you have disabled to breakpoint
305 previously.
306
307 \section3 ignore <breakpoint-id> <count>
308
309 Sets the ignore-count of a breakpoint, i.e., the breakpoint will not
310 stop the program execution unless it have been reached \c count
311 times. This can, for instance, be useful in loops to stop at a
312 specific iteration.
313
314 \code
315 .ignore 1 5
316 \endcode
317
318 Specifies that breakpoint 1 should be ignored the next 5 times it is
319 hit.
320
321 \section3 info breakpoints
322
323 Lists the breakpoints that are set.
324
325 \code
326 .info breakpoints
327 \endcode
328
329 \section3 tbreak <location>
330
331 Sets a temporary breakpoint. This command is identical to the
332 \c{break} command, only the breakpoint will be automatically deleted
333 the first time it is hit.
334
335 \section2 File-related Commands
336
337 \section3 list <location>
338
339 Lists the contents of a script around a given location, where the
340 location is given as a line number and, optionally, the name of the
341 file from which you will print. If only a line number is given, \c
342 {.list} will use the file of the current stack frame.
343
344 \code
345 .list foo.qs:125
346 \endcode
347
348 When no arguments are given, \c{list} will incrementally list
349 sections of the current script.
350
351 \section3 info scripts
352
353 Lists the scripts that are currently loaded.
354
355 \section2 Execution-related Commands
356
357 \section3 advance <location>
358
359 Advances execution to a given location. The syntax of the location
360 is the same as for setting breakpoints. For example:
361
362 \code
363 .advance foo.qs:125
364 \endcode
365
366 \section3 continue
367
368 Continues execution normally, i.e, gives the execution control over
369 the script back to the QScriptEngine.
370
371 \section3 eval <program>
372
373 Evaluates a program.
374
375 \section3 finish
376
377 Continues execution until the current function exits and the next
378 statement is reached (i.e., the statement after the call to the
379 function).
380
381 \section3 interrupt
382
383 Requests that execution should be interrupted. Interruption will
384 occur as soon as a new script statement is reached.
385
386 \section3 next <count = 1>
387
388 Continues execution until a new statement is reached; but if the
389 current statement is a function call, the function call will be
390 treated as a single statement. This will be done \c count times
391 before execution is stopped; the default is one.
392
393 \section3 return <expression>
394
395 Makes the current frame return to its caller. If \c expression is
396 given, it will sent as the result of the function (i.e., replacing
397 the functions return value). \c expression can be any valid QScript
398 expression.
399
400 \section3 step <count = 1>
401
402 Continues execution until a new statement is reached. If the number
403 \c count is given as argument, this will be done \c count times
404 before execution is stopped. As opposed to \l{next <count = 1>}, \c
405 step will enter functions when encountering a function call
406 statement.
407
408 \section2 Stack-related Commands
409
410 \section3 backtrace
411
412 Shows a backtrace of the current execution. The trace will list the
413 function name and its position in the script for each stack frame.
414
415 \section3 down
416
417 Selects the previous (inner) stack frame. The execution will not
418 return to this frame, but you will get access to its local
419 variables.
420
421 \section3 frame <index>
422
423 This command moves to the stack frame with the given \c index. The
424 index of the frame on the top of the stack is 0. Previous frames are
425 numbered from 1 and upwards (the bottom frame in the stack has the
426 largest index).
427
428 \section3 info locals
429
430 Lists the variables that are in the scope of the current frame.
431
432 \section3 up
433
434 Selects the next (outer) stack frame.
435
436*/
Note: See TracBrowser for help on using the repository browser.