program locks up using graph3d

[jhxcx]

I've been trying to use the CNiGraph3D control in an MDI application using MS Visual C++ 6 and I've been experiencing multiple lock up problems.

If the graph control is added to a dialog resource, then Visual C++ itself will lock up whenever this dialog resource is displayed. This even happens with the Measurement Studio example projects.

If instead, you make a graph control a member of a dialog class and then create it when the dialog is created, when the application runs, eventually it will lock up if the graph is displayed. You don't even have to do anything, just wait. Happens with both the Debug and Release versions. The Measurement Studio examples don't hang, but that may be because they are modal dialog applications, not MD
I.

I've updated to Measurement Studio 7 for Visual Studio 6 and that does not fix the problem. Has anyone seen this before? Have ideas on how to work around it? This is on a Windows 2000 machine with all current service packs, etc. and Visual Studio 6 with current service packs.

[jhxcx]

I have a little more information about this problem. It appears that there is some conflict with the CNiGraph3D control and the MS Flex Grid control. If I make a formview with a CNiGraph3D in it, and put the CMSFlexGrid in the about box dialog, everything works fine until the about box is displayed. If you had interacted with the 3D graph already, the program will lock up before displaying the about box. If you have not interacted with the 3D graph yet, the program will lock up on the next interaction with the 3D graph after closing the about box.

Visual C++ 6 also still hangs whenever a dialog is displayed that contains the 3D graph. For instance, display a dialog resource containing the graph, close the dialog resource and then try to do something like compi
le.

[JuanCarlos]

Hi,

This is a very strange problem, I've been doing some testing here loading a form that contains a 3D graph and a FlexGrid control and I don't see any issues when editing or running the form. I tested this with the modal dialog examples and in a MDI project.

One thing that you can try is to use the 3D graph with another ActiveX control and see how they interact. You can also play with the graphic acceleration on your computer and the color depth, this setting could change the way the 3D plotting is handled.

Please let me know any further information that you have on this.

Regards,

Juan Carlos
N.I.

[jhxcx]

Hmm, I see the problem consistently across different projects that I've made using this control. Sometimes it takes a little while before the lock up occurs, usually if I sit and rotate the graph for a minute or two, eventually it will hang. In other projects, it hangs immediately when the two are displayed.

Next, I will probably try wiping a drive and reinstalling a clean OS and install Visual Studio and Measurement Studio and see what I get. If it would help, I could also send you a Visual C++ project that exhibits this problem...

Thanks.

[jhxcx]

I tried using the MS Hierarchical Flex Grid and it also locks up. I also tried using the MS Data Grid and it also locks up.

I installed Visual Studio .NET and also tried the same things there and it locked up Visual Studio .NET as well. I cannot fully move over to .NET yet, but I just wanted to try it to see if there was a difference.

I'm fairly convinced now that there is a problem in the 3D graph OCX and that it does not play well with some other objects.

I saw some references in these forums about perhaps initializing the control with an argument like CNiInterface::SingleThread, but my version of Measurement Studio does not define CNiInterface or take a constructor argument for CNiGraph3D.

[jhxcx]

Ok, well I decided to wipe my system, reinstall the OS and start again fresh. This appears to have resolved the issue. When I opened my old project, the Measurement Studio Project Conversion Wizard appeared and after converting the project, it appears to be working. Simply upgrading Measurement Studio on my previous OS did not bring up the conversion wizard. I wonder if that would have fixed the problem there... regardless, it appears to be resolved now.