I'm doing development for Blackberry 10 using Cascades, which includes QT and QML. I find that I sometimes make mistakes in my QML file, but they don't get picked up at compilation time. How can I check whether I've made a syntax error, or mis-named a function call, or other typical errors?
QML is a dynamic language that is evaluated at Runtime. There is no compilation step and due to the nature of javascript and the dynamic nature of the global context there is no way for it to tell if what you are writing is correct/incorrect until it is evaluated. QtCreator can help with some of the QML errors you will find, but there is unfortunately no good way to get syntax errors about your javascript until it is evaluated and it explodes.
Personally, I have found good usage of the debugger to be the key to making these sort of fixes easy.
tldr; Keep your javascript clean and to a minimum there is no compile time checking.
open terminal in IDE connect your device or emulator using blackberry-SSH after connecting enter slog2info it show syntax and all typical error JavaScript with description and line NO.
If there are any mistakes it will show those lines in RED marks. It is dynamically checks there is no need to worry about compile.
If you done wrong you will not see the DESIGN CONSOLE correctly.
Related
I am currently working with python and Qt which is kind of new for me coming from the C++ version and I realised that in the oficial documentation it says that an UI file can be loaded both from .ui or creating a python class and transforming the file into .py file.
I get the benefits of using .ui it is dynamically loaded so no need to transform it into python file with every change but what are the benefits of doing that?, Do you get any improvements in run time? Is it something else?
Thanks
Well, this question is dangerously near to the "Opinion-based" flag, but it's also a common one and I believe it deserves at least a partial answer.
Conceptually, both using the pyuic approach and the uic.loadUi() method are the same and behave in very similar ways, but with some slight differencies.
To better explain all this, I'll use the documentation about using Designer as a reference.
pyuic approach, or the "python object" method
This is probably the most popular method, especially amongst beginners. What it does is to create a python object that is used to create the ui and, if used following the "single inheritance" approach, it also behaves as an "interface" to the ui itself, since the ui object its instance creates has all widgets available as its attributes: if you create a push button, it will be available as ui.pushButton, the first label will be ui.label and so on.
In the first example of the documentation linked above, that ui object is stand-alone; that's a very basic example (I believe it was given just to demonstrate its usage, since it wouldn't provide a lot of interaction besides the connections created within Designer) and is not very useful, but it's very similar to the single inheritance method: the button would be self.ui.pushButton, etc.
IF the "multiple inheritance" method is used, the ui object will coincide with the widget subclass. In that case, the button will be self.pushButton, the label self.label, etc.
This is very important from the python point of view, because it means that those attribute names will overwrite any other instance attribute that will use the same name: if you have a function named "saveFile" and you name the button "saveFile", you won't have any [direct] access to that instance method any more as soon as setupUi is returned. In this case, using the single inheritance method might be helpful - but, in reality, you could just be more careful about function and object names.
Finally, if you don't know what the pyuic generated file does and what's it for, you might be inclined to use it to create your program. That is wrong for a lot of reasons, but, most importantly, because you might certainly realize at some point that you have to edit your ui, and merging the new changes with your modified code is clearly a PITA you don't want to face.
I recently answered a related question, trying to explain what happens when setupUi() is called in much more depth.
Using uic.loadUi
I'd say that this is a more "modular" approach, mostly because it's much more direct: as already pointed out in the question, you don't have to constantly regenerate the ui files each time they're modified.
But, there's a catch.
First of all: obviously the loading, parsing and building of an UI from an XML file is not as fast as creating the ui directly from code (which is exactly what the pyuic file does within setupUi()).
Then, there is at least one relatively small bug about layout contents margins: when using loadUi, the default system/form margins might be completely ignored and set to 0 if not explicitly set. There is a workaround about that, explained in Size of verticalLayout is different in Qt Designer and PyQt program (thanks to eyllanesc).
A comparison
pyuic approach
Pros:
it's faster; in a very simple test with a hundred buttons and a tablewidget with more than 1200 items I measured the following bests:
pyuic loading: 33.2ms
loadUi loading: 51.8ms
this ratio is obviously not linear for a multitude of reasons, but you can get the idea
if used with the single inheritance method, it can prevent accidental instance attribute overwritings, and it also means a more "contained" object structure
using python imports ensures a more coherent project structure, especially in the deployment process (having non-python files is a common source of problems)
the contents of those files are actually instructive, especially for beginners
Cons:
you always must remember to regenerate the python files everytime you update an ui; we all know how easy is to forget an apparently meaningless step like this might be, expecially after hours of coding: I've seen plenty of situations for which people was banging heads on desks (hopefully both theirs) for hours because of untraceable issues, before realizing that they just forgot to run pyuic or didn't run it on the right files; my own forehead still hurts ;-)
file tracking: you have to count two files for each ui, and you might forget one of them along the way when migrating/forking/etc, and if you forgot an ui file it possibly means that you have to recreate it completely from scratch
n00b alert: beginners are commonly led to think that the generated python file is the one to be used to create their programs, which is obviously wrong; unfortunately, the # WARNING! message is not clear enough (I've been almost begging the head PyQt developer about this); while this is obviously not an actual problem of this approach, right now it results in being so
some of the contents of a pyuic generated files are usually unnecessary (most importantly, the object name, which is used only for specific cases), and that's pretty obvious, since it's automatically generated ("you might need that, so better safe than sorry"); also, related to the issue above, people might be led to think that everything pyuic creates is actually needed for a GUI, resulting in unnecessary code that decreases its readability
loadUi method
Pros:
it's direct and immediate: you edit your ui on Designer, you save it (or, at least, you remember to do it...), and when you run your code it's already there; no fuss, no muss, and desks/foreheads are safe(r)
file tracking and deployment: it's just one file per ui, you can put all those ui files in a separate folder, you don't have to do anything else and you don't risk to forget something on the way
direct access to widgets (but this can be achieved using the multiple inheritance approach also)
Cons:
the layout issue mentioned above
possible instance attribute overwriting and no "ui" object "containment"
slightly slower loading
path and deployment: loading is done using os relative paths and system separators, so if you put the ui in a directory different from the py file that loads that .ui you'll have to consider that; also, some package managers use to compress everything, resulting in access errors unless paths are correctly managed
In my opinion, all considering, the loadUi method is usually the better choice. It doesn't distract me, it allows better conceptual compartmentation (which is usually good and also follows a pattern similar to MVC much more closely, conceptually speaking) and I strongly believe it as being far less prone to programmer errors, for a multitude of reasons.
But that's clearly a matter of choice.
We should also and always remember that, like every other choice we do, using ui files is an option.
There is people who completely avoids them (as there is people who uses them literally for anything), but, like everything, it all and always depends on the context.
A big benefit of using pyuic is that code autocompletion will work.
This can make programming much easier and faster.
Then there's the fact that everything loads faster.
pyuic6-Tool can be used to automate the call of pyuic6 when the application is run and only convert .ui files when they change.
It's a little bit longer to set up than just using uic.loadUi but the autocompletion is well worth it if you use something like PyCharm.
I have added a reference to a DLL from another project (contained in the bin folder) and I have set Copy local to true. When I step through the code; the debugger jumps all over the place. I believe this is because the code is optimised. I have two questions:
Is this because the code is optimised
If (1) is true then why can I step through the code in the first place i.e. without Reflector.
My guess is the jumping is due to the PDB (symbols) being out of sync with the compiled DLL, thus the symbols tell VS to go to a line number that does not actually match up with what the code is actually doing; optimization may also play a part as well, because of in-lining functions.
Other things that influence the debugging experience are:
Just My Code setting
Methods explicitly marked with DebuggerNonUserCode attribute
Debugging optimized code may "jump around", as some functions become inlined. The most telling thing is that local variables usually get optimized away, giving a message to that effect when trying to read them.
If the jumping seems to make very little sense, though, then it's more likely you have the wrong PDB (which maps to line numbers) or source (which has the line numbers).
In writing a Qt4 app, I clumsily wrote:
QObject::connect(spinbox, SIGNAL(vlaueChanged(int)), ....
and it compiled, and it ran, but of course the spinbox didn't have any effect.
Such misspellings should be caught. I always assumed that valueChanged() was declared in some header file, but apparently not. Any arbitrary garbage can be given to SIGNAL() or SLOT(), and it'll compile. My toy program is small. For a huge app with dynamically created controls connected on the fly, an error like this could be very hard to track down.
Is there some way to do error checking for this kind of typo? Is it possible for the compiler (gcc) to do this, or is some other tool appropriate?
This has been changed for Qt5. You can read about it here.
SIGNAL and SLOT macros turn their arguments into strings, and they are not checked in compile time (because... they are string actually). In case of wrong signal/slot name Qt writes warning (qWarn) in runtime. They say, in Qt5 something changed there.
In my experience, sometimes you really can do such a mistake (though rarely, autocompletion helps a lot), but it can be easily tracked down and fixed.
I'm not sure if this is standard behavior for IDEs, but I personally find it irritating. If a file produces warnings when built (unused variables, mismatched ints/longs/etc.), those warnings will cease to be displayed if another file is modified and the "Build project" button is clicked. Doesn't it make more sense for warnings pertaining to unmodified code to continue to be displayed? Is there a way to force this behavior?
The warnings are displayed when the compiler emits them -- unfortunately, that's the design decision taken by both VS team (up to 2008 at least) and by Qt Creator team.
It seems to be standard behavior, and I don't know of any options to override it. It should be easy to fix in Qt Creator, but may be hard to fix in Visual Studio unless relevant APIs are present. For VS you'd need to write an add-in and there would need to be an API available that gives you read-write access to the error list and to the build process. If such APIs exist, then it'd be a simple thing to do as well.
This is "standard behavior", and more specifically, behavior is an attribute of how build systems on Earth "are-designed-to-behave".
As #Kuba notes, the warnings are emitted by the compiler. They aren't stored (except in the "log-of-all-errors/warnings" for the build operation, which the IDE typically never reads-back-and-excerpts-from-for-future-build-operations, which would get their own log of their new warnings/errors). Thus, you won't see the warning again unless the compiler actually compiles the file again, and that's because they would be new warnings that are generated again by the new build operation.
To get what you want (a clever thought, IMHO), the build system would need to:
store warnings from each file-compile (probably on a "per-file-basis")
recall/display those warnings each time that file-output-product was "used"
Very clever. I'm not aware of any system that does that. It would require fairly significant IDE or build-tool-level management of build products, which IMHO, none of them do well (but some are better than others).
This is the year 2012, and not only are we missing our flying cars, but we're missing build systems that merely/quickly build-only-what's-required-using-all-cores while easily handling different configurations. Both were expected by now.
Then, sometime after that, you could probably get your feature. That would be a bonus, because then you could use it in your flying car.
I noticed that modal dialogs on QT uses a local QEventLoop with the ProcessEventFlags set as "DialogExec"
eventLoop.exec(QEventLoop::DialogExec);
The QT assistant has no information on what this enum means. There is another one called EventLoopExec. Anyone has any idea what they actually mean and why aren't they documented?
Thanks
I did some poking around and this is what I found:
This enum is intentionally omitted from the documentation, along with several other QEventLoop::ProcessEventsFlag enum values (X11ExcludeTimers, ExcludeUserInput, WaitForMore, EventLoopExec) as there is an \omitvalue in front of each one in the comments that generate the docs.
There is only one place in all of Qt that actually uses it, in qeventdispatcher_mac.mm in which it appears to be some kind of mac-specific optimization according to the in-line comments
The intentional omission of these values from the docs leads me to conclude that they're for internal Qt use only, and that you shouldn't need to use them or worry about them.