@J-Hilk Thanks! Hope it can be fixed soon.
@jsulm Same thanks!

Export watcher:

int main(int argc, char *argv[]) { QCoreApplication::setAttribute(Qt::AA_EnableHighDpiScaling); QGuiApplication app(argc, argv); QQmlApplicationEngine engine; const QUrl url(QStringLiteral("qrc:/main.qml")); QObject::connect(&engine, &QQmlApplicationEngine::objectCreated, &app, [url](QObject *obj, const QUrl &objUrl) { if (!obj && url == objUrl) QCoreApplication::exit(-1); }, Qt::QueuedConnection); QFileSystemWatcher watcher; watcher.addPath("data.json"); readJSON myGlobal; engine.rootContext()->setContextProperty("myGlobalObject", &myGlobal); engine.rootContext()->setContextProperty("watcher", &watcher); engine.load(url); return app.exec(); }

and use Connections:

Window { visible: true width: 800 height: 800 title: qsTr("Screen Display") DisplaysForm { function callCPP(text) { var dataOne = myGlobalObject.readingJson(text) dataOne = parseFloat(dataOne) return dataOne } function updateDisplay() { var value = callCPP("Engine_Spd") engSpd_txt.text = value var value1 = callCPP("Engine_Power") engPwr_txt.text = value1 } Connections{ target: watcher function onFileChanged(path){ console.log(path) updateDisplay() } } }

@Core2
You are welcome :)

it takes some time to get used to design/program
with signals and slots.
It can be a bit of a challenge to have pointers to both objects in same place but often the mainwindow is a good place.

Note that its also ok to connect signal to signal.
This can be used to surface some signals from inside a class to outside world.
Like if you have a dialog with an TextEdit. The textEdit is private so outside cannot
connect directly to it.
You can then connect signal to a new public signal and the outside world can connect to this new signal. ( like TextReady)

The good thing about this is that if you one day change the TextEdit to a combobox, the rest of the program do not need to change. It will still get the data via the new public signal TextReady.
In a non trivial program, such encapsulation/hiding of details is
worth every penny.

difference between exec() and show(),
Only QDialog have exec() Qwidgets have show.
When you call show on a Dialog, it becomes visible but do not
wait for input.
example mainw::func() { MyDialog *dia=new MyDialog(this); dia->show(); int a=0; // this code is run the moment dialog is shown on screen, } using exec() mainw::func() { MyDialog dia; dia.exec(); int a=0; // this code is run only after dialog is dismissed. }

The version of dialog where u call show() could be called floating so when user click ok
it should emit signal that something should happen. ( to maiwindow )

The exec() version will report back the result ok/cancel/closed at once.

learn when to use QObject, QWidget, QFrame
QWidget is often used if making own widget. QFrame is used if you just need something to draw
a frame. If you use Designer you can check out the Widgets that are available.
QDialog is useful for any type of windows that pop ups up or open via a menu.

I have to set anything inside Register.
Yes, Register should be able to give the data back.
the widgets inside are private so you need a function to return the data.
You might also need to call
http://doc.qt.io/qt-5/qdialog.html#accept
in your Register buttons clicked slot.

@namit
ok super.

@qtacc32
If you're still struggling with this if possible try sharing a real piece of the code. It might be something trivial that doesn't show up in the example (which looks fine). Or at least a MWE that reproduces the problem, since I could not run your example, since it's not complete.

Kind regards.