How to avoid repeated execution of loading Qlibrary?
-
I notice, afterwards, that the declaration should not have parentheses :
class MainWindow : public QMainWindow { Q_OBJECT QLibrary myLib; typedef FDXSDK_ERROR_TYPES(__stdcall* Fn6)(void); Fn6 RB_StartMeasurement; ...But then, in the constuctor, I could not understand why I was still the error "Too many arguments to function call" when I tried to pass the name of the DLL to the load library function:
MainWindow::MainWindow(QWidget *parent) : QMainWindow(parent) // Constructor , ui(new Ui::MainWindow) { ui->setupUi(this); bool Result; Result = myLib.load("DEVICE.dll"); RB_StartMeasurement = reinterpret_cast<Fn6>(myLib.resolve("FDX_StartMeasurement")); }It's one thing to declare myLib as of type Qlibrary in the header but I don't understand, why in the implementation, the compiler would complain?
jsum commented earlier :Why do you declare another myLib inside constructor?! Use the class instance myLib.
So I think, that is what I'm doing, using the class instance myLib.
Unless I leave the call to Load without arguments, like this :bool Result; Result = myLib.load();But this does not seem to make sense?
The documentation states:
The resolve() function implicitly tries to load the library if it has not been loaded yet.
But where will it gets the name of the DLL to load in memory, if it is never specified in the first place?Take the Measure button code :
void MainWindow::on_btnMeasure_clicked() { sdkError = RB_StartMeasurement();Where is the application going to get the DLL from?
@RogerBreton said in How to avoid repeated execution of loading Qlibrary?:
But where will it gets the name of the DLL to load in memory, if it is never specified in the first place?
Via the ctor
I was still the error "Too many arguments to function call" when I tried to pass the name of the DLL to the load library function:
Because you declared a class function named
myLib()which returns a QLibrary object. -
wrote on 29 Apr 2021, 17:37 last edited by
I wanted to try the changes in debug mode but I immediately ran into the following error message :
Time for a cup of coffee...
-
@RogerBreton said in How to avoid repeated execution of loading Qlibrary?:
Time for a cup of coffee...
I would rather say - time for a debugging session :)
-
I wanted to try the changes in debug mode but I immediately ran into the following error message :
Time for a cup of coffee...
wrote on 29 Apr 2021, 17:49 last edited by JonB@RogerBreton
If, from what you have shown, you presently have:bool Result; Result = myLib.load(); RB_StartMeasurement = reinterpret_cast<Fn6>(myLib.resolve("FDX_StartMeasurement")); sdkError = RB_StartMeasurement();without checking the intermediate return result variables,
RB_StartMeasurementmay benullptr. ThenRB_StartMeasurement()would cause aSIGSEGV? -
@RogerBreton
If, from what you have shown, you presently have:bool Result; Result = myLib.load(); RB_StartMeasurement = reinterpret_cast<Fn6>(myLib.resolve("FDX_StartMeasurement")); sdkError = RB_StartMeasurement();without checking the intermediate return result variables,
RB_StartMeasurementmay benullptr. ThenRB_StartMeasurement()would cause aSIGSEGV?wrote on 29 Apr 2021, 18:17 last edited by@JonB I don't dare say RB_StartMeasurement may be a nullptr in ALL LIKELIHOOD, and that maybe the cause of the segmentation fault. That is exactly my hypothesis. So, if that is the case, this proves my intuition : where is the application getting the DLL from? If its name isn't specified anywhere? It is not in the PRO file.
I was thinking, perhaps, I should test whether the library is loaded before calling RB_StartMeasurement? And if it is not loaded, then load it? But that would not explain why I get the SIGSEV when the application tries to load? Or is it happening in the constructor?
Somehow, I must be missing some important piece of the puzzle -- I'll continue to look around but I am optimistic...
-
@JonB I don't dare say RB_StartMeasurement may be a nullptr in ALL LIKELIHOOD, and that maybe the cause of the segmentation fault. That is exactly my hypothesis. So, if that is the case, this proves my intuition : where is the application getting the DLL from? If its name isn't specified anywhere? It is not in the PRO file.
I was thinking, perhaps, I should test whether the library is loaded before calling RB_StartMeasurement? And if it is not loaded, then load it? But that would not explain why I get the SIGSEV when the application tries to load? Or is it happening in the constructor?
Somehow, I must be missing some important piece of the puzzle -- I'll continue to look around but I am optimistic...
wrote on 29 Apr 2021, 18:27 last edited bybool Result; Result = myLib.load(); if (!Result) qDebug() << "This is bad..."; RB_StartMeasurement = reinterpret_cast<Fn6>(myLib.resolve("FDX_StartMeasurement")); if (RB_StartMeasurement == nullptr) qDebug() << "This is bad. Get ready for SEGV if you call RB_StartMeasurement() now..."; sdkError = RB_StartMeasurement(); -
wrote on 29 Apr 2021, 18:29 last edited by
I declared the RB_StartMeasurement as NULL in mainwindow.h :
class MainWindow : public QMainWindow { Q_OBJECT QLibrary myLib; typedef DEVICE_ERROR_TYPES(__stdcall* Fn6)(void); Fn6 RB_StartMeasurement = NULL;But I still get the Segmentation Fault...
-
Hi,
Did you implement @JonB´s suggestion ?
Start in debug and you should see exactly where it fails.
-
Hi,
Did you implement @JonB´s suggestion ?
Start in debug and you should see exactly where it fails.
wrote on 29 Apr 2021, 19:11 last edited by@SGaist That is exactly what I do :
I found the culprit...
DEVICE_ERROR_TYPES sdkError = RB_RegisterDeviceEventHandler(EventNotice);The above function is a static member function declared in SomeClassName... which was working fine before ... The EventNotice function is also part of the same class.
-
wrote on 29 Apr 2021, 20:03 last edited by
For some reason (?), the EventNotice "address" is garbage :
EventNotice 2372415452829272149 void (DEVICE_eEventCode, uint32_km, DEVICE_ERROR_TYPES)
It should be a proper address like 0x00007ff739a21970.
I tried restarting QT Creator many times to no avail. -
wrote on 29 Apr 2021, 23:31 last edited by
Thank you all for your patient help.
I'm putting QT on the backburner for now.
Too bad. Such a nice environment.
22/23