Forum

Hello,

just by switching to 280 from 264 (without changing anything in my code) I started to experience app crash when moving default html help window out of the screen. Here is the procedure:
1) I start my app and switch to CExtPaintManagerOffice2007_R1 using g_PaintManager.InstallPaintManager
2) I use default MFC HTML Help feature, so I open the help window by pressing F1 or going to Help/Help Topics menu item
3) Help window opens - so far so good
4) When I move part of the HTML Help window out of the screen, the HTML Help window jumps automatically to the center of the screen (without my interaction) and debug assertion pops up (or crash when in Release mode)

Any ideas why this is happening? As said before, in 264 was everything working fine.

screenshot is here:
http://kasa.chassco.net/htmlhelpCrash.PNG

is there a ProfUIS way to handle HTML Help (maybe a special class?) or is it still better to use default MFC HTML Help?

thanks,
krompo

If you are having problems with investigating the problem further and you really need my app sources, I can provide it to you but for that I need your private email where I could send them.

It seems we cannot say what is wrong based on the call stack information:

Problem0123.PNG

So we need to debug your project either remotely or on our side. In the latter case, please provide us with a project that reproduces the crash. You can send it to support@prof-uis.com.

Hello,

I just figured out that described crash happens when I move over my app with any application window, not just the help window of my application. I tried it with several application (including Total Commander and default Windows windows like Explorer) - in all cases the behaviour was the same - my app using ProfUIS 2.80 has crashed the same way as described in this thread above.

I need this crash behaviour to be fixed somehow otherwise I will not afford to purchase a full ProfUIS license what is what I planned to do.

krompo

I rebuilted the demo app to use ProfUIS and MFC dlls instead. Do you think you could try it once again? The new link is here:
http://kasa.chassco.net/IRMeasureDemoBugDLL.zip

Hopefully it works. If not, when do you think we could perform the remote conference? However, hopefully you can now at least debug the MFC and ProfUIS code to see it on your own.

thanks,
krompo

I forget to mention that the MFC CListCtrl I am using is in the bottom right part of the main app window. As you can see there are 4 elements in the list. Every of these elemets has assigned a non zero ItemData value. Such ItemData values are assigned to the CListCtrl control when the app launches and are never changed during the app execution. That means that they always contain non-zero values. Therefore it is quite weird that the GetItemData call on one of these 4 elemets returns 0 since they are always true.

We are not sure the list control in your application affects somehow to HTML view control. We have downloaded the ZIP file with your compiled application. The IRMeasureDemo.exe does not use Prof-UIS and MFC libraries as DLLs. So, it would be very difficult to debug the problem.

We think the fastest way to help you is organize remote conference on your desktop using services like WebEx or GoToMeeting

the problem is that the program is already quite complex and it would take too much time to reproduce it to a new project. Do you think you can get some clues if you run the debug version binary? you can download it here:
http://kasa.chassco.net/IRMeasureDemoBug.zip

The app is running 2 threads. The problem (MFC assertion) occurs in MFC’s winctrl2.cpp of MFC CListCtrl when I want to get the GetItemData:
DWORD_PTR CListCtrl::GetItemData(int nItem) const
{
    ASSERT(::IsWindow(m_hWnd));
    LVITEM lvi;
    memset(&lvi, 0, sizeof(LVITEM));
    lvi.iItem = nItem;
    lvi.mask = LVIF_PARAM;
here:    VERIFY(::SendMessage(m_hWnd, LVM_GETITEM, 0, (LPARAM)&lvi));
    return lvi.lParam; <- this sometimes returns 0 (and crashes) even that real value is true (the value in the list is always true)
}

Problem is that sometimes (randomly) GetItemData returns 0x0000 even that there is DEFINETELY another value as zero in mentioned ItemData value. Until ProfUIS 264 this error never happened. Do you remember what you added in ver 270 or later concerning CListCtrl handling?

To invoke the crash in the above binary:
1) run the app
2) confirm the COM1 setting in the shown dialog box
3) when app starts, push F1 (to invoke help) and move continuously with the help window - after a few secons the crash (assertion) pops up

If you have any clues please let me know.

btw: the windows HTML Help window is a separate new thread that is created when opening the window or does that code run in the main app thread?

krompo

One solution to this problem would be to use your native ProfUIS class for the HTML Help - do you have something like that? In that way I would not need to use Windows HTML Help (see the screenshot in the first message) and I could use your class instead. Do you think this is a way to go? I assume that in your native class problem as described in this thread will not exist.

krompo

HTML help is based on one API function invocation. It cannot be wrapped with a standalone class. You can see a simple HTML page control based on IE control in several sample applications provided with Prof-UIS (GLViews, SimpleGrids and ProfStudio). But this control displays one HTML page only. Unfortunately we did not receive similar reports about HTML help. So, we guess there is must be something specific in your project what produces the problem. We believe we can clarify what is wrong if you send it to us.

Hello Technical Support,

can you give me your insight into this problem? thanks.

krompo

Hello,

I played a little bit more with the app and found out:
1) It crashes even if I move the help window within the screen boundries (so I just move the window a few pixels and it crashes)
2) The crashing only happens in one of these 3 themes: Luna Blue, Obsidian, Office2007_R1 - how is that possible? In the rest of the themes the app never crashes! Please tell me what to do to fix this problem.

krompo

We are sorry for the delay with this reply. The crash problem seems really specific for your project only. We tried to reproduce the crash but failed. We used this simple project.

We did not receive similar reports from other users. Could you please insert your code into this project, reproduce the crash and send this project to us.

Please also note, you should use MFC/Prof-UIS window objects only in the same thread where they are created. If you need to update Prof-UIS tab control from another thread, you should use Win32’s InvalidateRect() API instead of CWnd::Invalidate().

I forget to mention that my app is running 2 threads: 1 regular main win thread (processing win messages) and 1 my own helper thread. the crash is happening in my worker thread and only if my worker thread is running. my worker thread is continuously updating the tab control in the upper right of the splitter (partialy seen in the screenshot). I don’t know how is win HTML Help implemented but I assume it is not running in a separate thread. Is this a clue for you? If the html help window is selected and my worker thread is updating the tab in main window it can in reality write to tab in html help window - however such tab does not exist in the helper window and that may cause the crash. Since this problem only occurs in 280, is there a way out of this or an idea why was this working fine in 264?

krompo