Jump to content
Tobias Schenk

Problem with passing a reference of an Object to the GUI

Recommended Posts

Hello uGFX Community,

I am currently trying to pass a reference of an object (DEngine) to my uGFX GUI, this object is changed in a seperate thread which is running in the main program. But somehow those changes do not apply to the reference of the object in the GUI even it is the correct instance of the DEngine object. I found out that the problem is the "gfxInit();" without it the cout gives back the correct values.

 

Does anybody has some experience with that or knows if it is possible to realize it like that, without either running the whole program using uGFX threads or seperating the GUI from the rest of the program?

 

That is how the important part of my GUI loop looks like:

void GuiLoop(bool master, DEngine *dengine)
{

    //Get the Fonts we want to use
    dejavu12 = gdispOpenFont("DejaVuSans12");
    dejavu16 = gdispOpenFont("DejaVuSans16");
    dejavu18 = gdispOpenFont("DejaVuSans18");
    dejavu20 = gdispOpenFont("DejaVuSans20");
    dejavu24 = gdispOpenFont("DejaVuSans24");
    dejavu28 = gdispOpenFont("DejaVuSans28");
    dejavu32 = gdispOpenFont("DejaVuSans32");
    dejavubold54 = gdispOpenFont("DejaVuSansBold54");
    dejavubold80 = gdispOpenFont("DejaVuSansBold80");

    //Initialize the Display
    //gfxInit();

    //Setting the Init Variables
    //setVariablesInit();

    //Creating our Widgets
    createConsole(White, Black, dejavu12);
    createParkingButton();
    createStartStopButton();
    createCustomSettingsButton();*/
    createSettingsPage();

    //Draw the Init Display
    drawDisplayInit();

    //Event Listener for Buttons
    geventListenerInit(&gl);
    gwinAttachListener(&gl);

    //Timer for Redrawing the Screen
    gtimerInit(&GT1);

    //Redraw Changed Parts every time_rw ms
    gtimerStart(&GT1, drawDisplayVariable, 0, TRUE, time_rw);
    
    while (1) {
      gfxSleepMilliseconds(100);
        load = dengine->GetLoad();
        vpedal = dengine->GetVpedalActual();
        rpm_de = dengine->GetRPM();
        std::cout<<dengine->GetRPM()<<std::endl;

...}

Thank you very much in advance.

Tobi

Share this post


Link to post
Share on other sites

Hello Joel,

thank you for your answer, its running on a Lenovo Yoga with an Intel i7 processor, I am using Linux (Ubuntu 17.10)  64Bit, the compiler is GCC and I m sorry but I dont really know what exactly you mean with "Who is managing the memory".

Share this post


Link to post
Share on other sites

Thanks inmarket for the hint, I will change that in my code, but that did not cause any problems so far and does not seem to be the reason for my problem as I tryed to comment out all uGFX code and checked the output of cout and adding/removing gfxInit() causes the cout to be correct and having the updated dengine->getRPM() value or not.

Share this post


Link to post
Share on other sites

This sounds very odd...

Can you please try to add another cout call with a static text? For example:

    while (1) {
      gfxSleepMilliseconds(100);
        load = dengine->GetLoad();
        vpedal = dengine->GetVpedalActual();
        rpm_de = dengine->GetRPM();
      	std::cout << "foo" << std::endl;
        std::cout << dengine->GetRPM() << std::endl;
      	std::cout << "bar" << std::endl;
  	}

Also, what compiler optimization level are you using?

Share this post


Link to post
Share on other sites

Thank you for the response, I am not using any compiler optimization "-O0".

The static cout calls dont change anything.

While the gfxInit is commented out I get an output like: 

foo

812

bar

foo

864

bar ...

etc. and with the gfxInit the output looks like:

foo 

812

bar

foo 

812

bar ...

Can't really explain what could cause this :/

Share this post


Link to post
Share on other sites

Just to be sure: When using the gfxInit routine, does the object still get altered in your main? Maybe the problem is not your GuiLoop.

Share this post


Link to post
Share on other sites

I am sorry for the long response time lately but I was just in the middle of exams, yes I checked that, the object is still altered just not in the GuiLoop, for me it appears like that after including gfxInit it is just making a copy of that object.

Share this post


Link to post
Share on other sites

I will try to give a better explanation of the rest of the program, in the main there is running a seperate thread for updating the object and this thread has its own stack where the object is located. Therefore I asume that uGFX is creating an additional thread which causes the GuiLoop to not run in the main thread anymore and therefore losing access to the object. 

Is it possible that this is the cause of the problem? Or can you try to explain how uGFX handles its threads?

Share this post


Link to post
Share on other sites

uGFX uses the underlying operating system to handle it's threads - in your case linux. uGFX puts a very thin wrapper around it just to make the API consistent across OS's.

Creating a stack variable in one thread and using it in another thread is no problem at all provided the original stack frame is still valid ie you haven't returned from the function that allocated the stack variable.

Share this post


Link to post
Share on other sites

Somehow that is not working in my case, I tried to rewrite the program using only uGFX threads and also to save the object in the Heap, but nothing could solve my problem.

I tried to cut my program to the essential parts, to be able to show my problem, app_init.cpp is creating and handling the thread which is responsible for changing the value and ugfxTest.cpp should just display the passed value but somehow that wont work. I can't really explain what could be the reason for this, if someone has an idea or could have a look into it I would appreciate it a lot.

the program is started adding -g due to the setup in main.cpp: ".build/FolderName -g"

Makefile

gfxconf.h

app_init.h

data_container.h

no.cpp

no.h

ugfxTest.h

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×