Windows 7 Debugging Issues

[Double_D]

I have been able to duplicate my problem with the code attached.  This is a stripped down subset of the actual program.  This program calls 3 threads -  the main thread, a comm thread, and a gui thread.  If I run this program in the debugger, all of the thread functions are scheduled and begin running.   When gui_cb_first_pannel is called in the gui thread, the call to LoadPanel (line 87 of GUI_Functions.c) runs fine.  When the DisplayPanel statement is executed, however, nothing happens (i.e., the panel is not displayed).  This thread seems to be unresponsive at this point.  In addition, the comm thread also seems to stop working.  If I break execution, the program always breaks in the main thread.  I added breakpoints in the other two threads and these are never reached.  This behavior is similar to what I experience with the "real" program.

[Perry_S]

Hi Double_D,

It seems that there might be an issue with how your threads are interacting with each other. How many threads are you expecting? The Panel that is not displayed what does it have on it? Are you referring to the login screen? Let me know what you are expecting.

Regards,

Perry S.

[Double_D]

In this stripped down version, the main thread schedules functions to run in two other threads - a thread which monitors TCP communication and a thread which displays the user interface.  The user interface thread is supposed to display the login screen (g_login.uir).  The gui_interface function runs and calls gui_cb_first_pannel, which  loads the login panel.  The call to LoadPanel is successful, but when DisplayPanel is called, nothing happens.  The login screen is not displayed and the gui_cb_first_pannel call never returns.

[D_Biel]

Double_D,

I was not able to reproduce this behavior. On my Win7 system, the panel displays and I see a login window. I can then enter in information and hit loging, which then of course causes errors, but I think that gets past where your system was failing.

I would suggest that you create a copy of the project and start removing parts of the project until you see a change in behavior. Start with the networking functions. Do you think the networking thread might be related?

Also, I see a function called debug_ui_main, is this supposed to execute?

You are also calling DiscardPanel(panelHandle), but I do not see a call to LoadPanel for this panel (except in teh debug_ui_main).

Also, while you can create panels in multiple threads, it is often simpler to manage them from the main thread. This reduces the likelihoood of multithreading issues that are common for GUI intensive applications. Typically, RunUserInterface is only called once, and that is in the main thread.

[Double_D]

I ran the program on a dual-core XP machine and the login panel displayed correctly for me, too. 

The call to debug_ui_main was removed to simplify the project for debugging purposes.  I commented out the call that schedules

the network thread on the Win 7 machine and the call to DisplayPanel once again never returned.  That leaves only two threads running - the main thread, which essentially does nothing right now and the gui thread.  There isn't much left to remove at this point.

Since the program ran on a dual-core XP machine for me and (assuming your machine is multi-core as well) on a Win 7 box for you, then perhaps the issue is not related to multicore.  Are there any configuration settings that I need to be aware of on Win 7?  The Win 7 box is running CVI 9, while the XP box has CVI 10 installed.  Perhaps the next step would be to update the CVI installation and see what happens.

[D_Biel]

You not have to make any special configuration for Windows 7. I am not aware of any known issues between CVI 9.0 and CVI 2010 that would cause these symptoms, but it may be a good idea to upgrade the Run-Time Engine on the Win7 system anyway. If you do see a change in behavior, let me know so that I can document that.

[Double_D]

I have made some progress by changing to a single RunUserInterface() call.  After these changes, if I also comment out calls to certain 3rd party library functions, I can get the login panel to display and I can interact with it.  When I quit the program, however, by clicking on a UI button, CVI throws a library error when a call is made to DiscardPanel for a particular panel.  This panel is created with the following:

         if ((panelHandle = LoadPanel (0, "back_ui.uir", PANEL)) < 0)
               return -1;

This panel displays correctly and I can use it.  The panelHandle value is 0, however, which is what causes DiscardPanel to fail.  The same code in my stripped down test version runs correctly and produces a value of 1 for panelHandle. 

What does the return value of 0 mean for LoadPanel?  The online help indicates that the panel is invalid (even though it displays), while a negative return value indicates an error. 

[D_Biel]

LoadPanel should not return 0. Are you sure that this LoadPanel was executed and that it stored the value in panelHandle. In the code you posted previously, the login window is the pnl_login. In fact, your original example doesn't even have a back_ui.uir file included. I could not find a code path that would ever cause this LoadPanel to execute. Maybe that is no longer the case with your new modifications. If you have made major changes, maybe you could post the new code.

[Double_D]

After getting as far as I could with the test code, I went back to the original (i.e., thousands of lines) code.  I probably didn't make that clear in my previous post.  LoadPanel was executed (I stepped through the code at that point) and the back_ui.uir panel was displayed.  The variable panelHandle was declared globally to a file as "static int".  After I removed the "static" qualifier, LoadPanel now returns a value of 1 and the program doesn't hang when the panel is discarded.  I'm not sure why this works, as the declaration is perfectly legal C code.

I don't have all of the kinks worked out yet.  My calls to QuitUserInterface don't end the program, probably because these calls are made from a different thread from RunUserInterface.  I also haven't tried to re-insert the calls to the 3rd party library functions that have been commented out.

An earlier post mentioned functions for specifying which processors to use for particular threads.  The best I can tell, though, is that these functions (SetProcessAffinityMask, etc.) are only available with the RT toolkit.  I did find a topic "Setting the Preferred Processor for a Thread" in the CVI help, but there is no further help for the functions and I can't find them in any of the installed CVI libraries.

[carlox]

Double_D, I even had warned you that those functions where Windows functions.

Look for SetThreadIdealProcessor or SetProcessAffinityMask() in the CVI help (these are Win32 API functions).

May be I put you on a wrong way with my suggestion to look into CVI help, but I intended to give you only an introduction to these functions, and I thought that - after reading that page - it would be obvious that the real documentation should be found elsewhere.

Here are the docs:

http://msdn.microsoft.com/en-us/library/windows/desktop/ms686253(v=vs.85).aspx

http://msdn.microsoft.com/en-us/library/windows/desktop/ms686223(v=vs.85).aspx