I got the following error message when upgraded to Qt 5.15:
QML Connections: Implicitly defined onFoo properties in Connections are deprecated.
Use this syntax instead: function onFoo(<arguments>) { ... }
The corresponding QML code is pasted below
Connections {
target: AppProxy
onLogsReady: function(logs) {
textLogs.text = logs
}
}
where the onLogsReady is a signal defined in the AppProxy class:
class AppProxy : public QObject {
Q_OBJECT
Q_DISABLE_COPY(AppProxy)
public:
AppProxy(QObject* parent = 0);
~AppProxy();
signals:
void logsReady(QString logs);
// ...
};
I wonder how to suppress this warning.
in Qml 5.15 there is a new syntax for connections. In your case it would look like this:
Connections {
target: AppProxy
function onLogsReady(logs) {
textLogs.text = logs
}
}
You can read more about it here: https://doc.qt.io/qt-5/qml-qtqml-connections.html
In addtion to #luffy and #Lidekys solution in my case adding this line to pro file of the project is solved issue.
DEFINES += QT_DISABLE_DEPRECATED_BEFORE=0x060000 # disables all the APIs deprecated before Qt 6.0.0
#luffy answer is correct, but not completely. If you'll just make these changes, at least for me, it didn't fix the issue. What fixed it was adding "import QtQml 2.15" (like stated in https://doc.qt.io/qt-5/qml-qtqml-connections.html) in the qml files that were affected by these changes.
Not sure if this helps, just wanted to add in to the issue.
Related
I work in Qt5.9.3, writing a qml program in linux platform without x window.
Following is my code:
import Qt3D.Core 2.13
Entity {
id: sceneRoot
...
Transform{
id: torusTransform
scale3D: Qt.vector3d(1.5, 1, 0.5)
rotation: fromAxisAndAngle(Qt.vector3d(1, 0, 0), 45)
...
}
However ,there is a underline in Transform in Qt creater.
The underline in Transform means something error happened.I am sure that Qt53DCore lib has added in .pro file.
So my question is:
How can I know the version of Qt3D.core ?
And how to ensure the specified qml type in the lib?
I don't know if there are a easy way but you can check the old Qt documentation to have an idea of which version you need.
In your example you should use import Qt3D.Core 2.0.
I search the "Entity" keyword in Qt5.9.3 folder, in .../Qt5.9.3/qml/Qt3D/Core path, there is a file named plugins.qmltypes.
I open it and found the code:
Component {
name: "Qt3DCore::Quick::Quick3DEntity"
defaultProperty: "data"
prototype: "Qt3DCore::QEntity"
exports: ["Qt3D.Core/Entity 2.0"]
exportMetaObjectRevisions: [0]
Property { name: "components"; type: "Qt3DCore::QComponent"; isList: true; isReadonly: true }
}
"exports: ["Qt3D.Core/Entity 2.0"]" tell me the version and qml type name.
My code runs fine as expected but why do I get the warning messsage:
QML Connections: Cannot assign to non-existent property "onValueChanged"
Here is how I linking to signal.
Connections {
target: myModel
onValueChanged: {
console.log("Valued changedRecieved in QML")
}
myModel is a C++ class that I am exposing to QML using engine.rootContext()->setContextProperty("myModel", &model);
Is there a way to remove this warning?
In your Connections scope just set ignoreUnknownSignals: true
Folks, I'm trying to do something that I thought ought to be simple, but I must be doing something wrong. I'm trying to simply have a clear structure in my meteor application which uses Typescript.
Here are my requirements:
All interfaces are available in both client and server
Some class implementations are only available on the server
I don't want to rely on file load order for my application to work properly
I need my own module to not clash with global objects (such as the Position class for example)
I need to have one monolithic include file for server, one for both client and server and one for client (don't want to have 10s of includes on top of my files)
The setup that I have right now is this
server
server-book.ts
client
shared
collections.ts
definitions
server
include.d.ts (includes all .d.ts files in this folder)
server-book.d.ts (server specific implementation of book)
client
shared
include.d.ts (includes all .d.ts files here)
book.d.ts (book interface definition)
collections.d.ts
In each .d.ts file I have
module MyModule {
interface Bla {}
};
In each .ts file that defines a class I have:
module MyModule {
export class MyBla implements Bla {};
}
All .d.ts files generated for classes are generated by tsc -d.
No .ts files are being included via ///<reference> rather only .d.ts files.
Now, when I run this, I get an error that MyModule is undefined:
/// <reference path="shared/include.d.ts"/>
/// <reference path="server/include.d.ts"/>
Meteor.startup(() => {
var temp = new MyModule.ServerBook();
});
The error occurs right on MyModule.
What am I doing wrong? What should be the proper setup here?
Thanks!
I have dealt with this issue on my blog. I decided to use the evil eval command, since it gave me the easiest possibility of using modules till something more sophisticated appears.
File /lib/foo.ts is position in the subdirectory since it has to be loaded before Bar.
eval('var Hugo = (this.Hugo || (this.Hugo = {})'); // this will override the automatically emitted var Hugo and assigns it with globally defined Hugo module
module Hugo {
export class Foo {
foo():string {
return 'foo'
}
}
}
File /bar.ts
/// <reference path="lib/foo.ts"/>
eval('var Hugo = (this.Hugo || (this.Hugo = {})'); // this will override the automatically emitted var Hugo and assigns it with globally defined Hugo module
module Hugo {
export class Bar extends Foo {
bar () : string {
return 'bar';
}
}
}
File /test.ts
/// <reference path="lib/foo.ts"/>
/// <reference path="bar.ts"/>
var m = new Hugo.Bar();
console.log(m.bar());
console.log(m.foo());
As mentioned here, for classes, the solution is even simpler:
class ExportedClass {
variable : int;
}
this.ExportedClass = ExportedClass;
Definition files should use the declare keyword. You would normally get an error if you didn't use this keyword.
declare module MyModule {
export interface Bla {}
}
And
declare module MyModule {
export class MyBla implements Bla {
}
}
It is also worth checking that the ServerBook class has the export keyword (just like MyBla in your examples).
After lot of trial and errors, here are my findings so far :
Using typescript "module" keyword doesn't get well with Meteor. I think at the moment you cannot use it (or the workarounds are too complicated for me).
However, here is what you can do :
Let say that you have package A where you want to define a class ClassToExport which you want to make public.
class ClassToExport {
getFoo(){
return "foo";
}
}
Please note that you can't write this.ClassToExport = ClassToExport and
api.export('ClassToExport') or else ClassToExport won't be available in the global scope of package A, hence the need for a module/namespace for exporting your class, which we will see next.
Now, for the class to be available for the consumers of your package, you have to create a namespace, which will be the equivalent of the "module" typescript keyword for internal module.
So let's write :
declare var packageA; //so that the compiler doesn't complain about undeclared var
packageA = packageA || {}; //so that this namespace can be reused for the entire package
packageA.ClassToExport = ClassToExport; //the actual export
Now, don't forget to write
api.export('packageA') in the package.js of package A
If you have a package B where you want to use ClassToExport, you write in package B:
var cte = new packageA.ClassToExport();
without forgetting to api.use package A in package B's package.js
If you don't want to write the namespace each time you use the class, you can also write var ClassToExport = packageA.ClassToExport; at the top of your using file.
If you need a global class for you package only, without exporting it, then you can do instead just :
this.ClassToExport = ClassToExport
and again don't write api.export('ClassToExport'), or it won't be available in the package anymore.
This way, i think the features (export/ import) of internal typescript modules are there.
If you are not afraid of gulp build, I have prepared a typescript boilerplate project which allows you to comfortably use typescript from within your app, not depending on packages.
https://github.com/tomitrescak/meteor-boilerplate-typescript
Random idea, what about extend Meteor instead of Window.
Meteor.yournamespace = Meteor.yournamespace || {};
Meteor.yournamespace.myclass = new MyClass();
or
Meteor.yournamespace.MyClass = MyClass();
I think this is less invasive than go directly to the window object IMHO. my two cents.
now you can do Meteor.yournamespace.MyClass :P
--EDIT
Then you could create a meteor-extend.d.ts file and do something like:
/// <reference path="main.d.ts" />
declare module Meteor {
var yournamespace: any;
}
Now you can remove the <any> before Meteor and Typescript will not complaint.
I'm creating QML application (QT 5.2)
Assume I have some object set as root context:
viewer.rootContext()->setContextObject(&view_model);
Now I want to bind to a signal of view_model from QML:
Connections {
target: ??? WHAT SHOULD GO HERE ???
onSignalStateChanged: console.log("signal")
}
Cannot figure out what should be the target.
Important: I don't want to use setContextProperty.
It seems you can't use Connections if you don't have access to object instance (via context property for example). But you still could use following:
function onSignal() {
console.log( "signal" );
}
Component.onCompleted: {
onSignalStateChanged.connect( onSignal );
}
Suppose you have
private static const INCLUDE_MY_DEBUG_CODE:Boolean = false;
public function runMyDebugCode():void
{
if ( INCLUDE_MY_DEBUG_CODE )
{
callADebugFunction();
}
}
private function callADebugFunction():void
{
...
}
Given there is no other reference to callADebugFunction, will it be guaranteed that callADebugFunction is not part of the compiled build?
If there no references to the file/class - then it's not going to be compiled.
In your case if you have reference from outside to this class - all the methods are going to be compiled.
Use compilation variables to eliminate debug code from release.
Go to Project->Properties->Flex Compiler and add
For debugging mode:
-define=CONFIG::release,false -define=CONFIG::debugging,true
or for release:
-define=CONFIG::release,true -define=CONFIG::debugging,false
Then in you function runMyDebugCode()
CONFIG::debugging {
trace("this code will be compiled only when release=false and debugging=true");
}
CONFIG::release {
trace("this code will be compiled only when release=true and debugging=false");
}
I highly doubt it. Since something IS referencing that function (regardless of whether or not it is reached at runtime), it is most likely that this code will in fact get compiled into your SWF/SWC file.
There are better ways to prevent debugging code from ending up in release builds. See zdmytriv's answer.