array visualizer activeX hangs my app

array visualizer activeX hangs my app

Hi,
I have developed an a VB application with the array viewer activeX control embedded in a form. There are lots of controls on the form that allow dynamic user manipulation of the display such as marker size, series to display etc.

What I am finding is that as it became more complicated my applicationshuts down (with the message asking if you want to send a report to Microsoft)pretty frequently, both in design mode and in the compiled exe.

It seems to happed about 1 in 4 times I use the app. There seems to be no specific reason why.

It is definately the array visualizer activeX causing the problem, and there seems to be no way to trap the error being caused and exit gracefully.

This is an issue as I can't use the array visualizer in an app if it is going to cause this to happen.

Has anyone else had any problems (and solutions?) My thought is that it is being caused by an unhandled exception in the activeX control.

Phil

publicaciones de 11 / 0 nuevos
Último envío
Para obtener más información sobre las optimizaciones del compilador, consulte el aviso sobre la optimización.

some more info and findings....

I have an app with a form that has 4 av controls on it - 1 3d plot and 3 2d plots. I am loading in and array that has about 10,000 points.

When running the app on a very high spec XP machine there is an error message from time to time and the app shuts down.

I registered the controls on a much lower specNT machine and cannot as yet get the controls to bring the app down when run on the NT machine. The 3d plot does give up when you try to rotate it too much, and just disappears from view. This is preferable though to giving an error message and bringing down the app.

I've monitored the cpu and memory usage and that seems to be OK. What I also noticed is that when I load the form with the controls on, I get 4 instances of AvMemFLSvr.exe. When I close the form these 4 instances persist, it is only when I close the app that they close. They also breed as I press buttons on the form (refreshing the graph) - I can get 10 instances - maybe this is just bad programming on my part.

My query is though, what has a low spec NT machine got that a high spec XP machine has not, and how can I solve this issue?

Phil

and more...

The error is being caused by the opengl32.dll

version

5.1.2600.2180 (xpsp_sp2_rtm.040803-2158)

Is this why I can't get it to crash on NT as it is a different version of the dll?

I created a VB6 project with 6 AvGraphCtls on a form (see the attached zip file), and didn't notice any problems. But I think it depends a lot on the graphics card and drivers you have installed. With 6 controls you have 6 connections to the driver and I suspect many vendors don't test that scenario very well since games usually only have one connection (since everything is displayed in one window).

There's an undocumented registry setting you can use to force software based rendering which should be more reliable. Save the following text to a .reg file and run it on the system experiencing the crash by double clicking on it in Windows Explorer:
Code:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USERSoftwareIntelArray VisualizerSettings]
"NoHWAccel"=dword:00000001

This should force all AV apps on that system to use software-based rendering.

Regarding the multiple copies of avmemflsvr.exe, you want to set the Root property of each control to the same instance of IAvGroup. You can create multiple graph objects off of the root group and have each control display a unique graph. This is what I do in the attached example and I'm only seeing one instance of avmemflsvr.exe. Another advantage of this approach is that if you later want to add file save functionality to your project, all the graphs and data can be saved just by passing the root group to the AvFileLoader object.

Here's a screen shot of the VB6 form with 6 controls...

Thanks.

I don't think you will get the error message with the app you developed. Mine is more complex with buttons to allow user to dynamically manipulate the plot. It is when this manipulation is performed that the crash 'sometimes' occurs.

I am still unable to get the crash to occur on my NT machine though. The 3d plot just gives up and disappears, but the 2d plots still behave OK.

The registry setting has improved things significantly, including speed, but I still get crashes from time to time ocuuring in openGL32.dll. Are there any more settings that will improve things?

Can you post your project? I'll take a look at it (of course there's no guarantee that I'll see the crash on my system).

I can't think of any other settings that would effectOpenGL rendering. If you go to the Control Panel, Display applet, you might find some settings that have an effect. Sometimes changing the color resolution (say from 16bit color to 24 bit color) can make a big difference. Also you might want to check with the vendor foryour graphics card and see if they have any driver updates.

John,

Attached is the vb project that causes the issues.

Please play around by resizing the form & pressing all the buttons.

Please also be patient and try it several times. The app crashes appear to be random. The error is in openGL32.dll.

The error still happens with the registry change suggested, but not as often.

Thanks,

Phil

I ran your project (which looks neat btw) and I'm seeing the crash as well!

It occurs in the following OpenGL call:

Code:

int nMaxLights = 0;
glGetIntegerv(GL_MAX_LIGHTS, &nMaxLights);

Which looks perfectly innocuous to me. Anyway, if I just set nMaxLights to 8 (the default for most cards) and comment out the glGetIntegerv call, the program seems to run without crashing. Until I find out more, I'll leave this change in (i.e. it should be in the next compiler update).

On a non-related front, try changing your code to set the Root property of each control in the form to the same group instance (as I did in the multigraph.zip project I posted). That way you won't have so many avmemflsvr processes running.

Thats good news.

I presume this means there is nothing I can do about it until the next release of the compiler?

Have you any idea when this will be - I am hesitent aboutdeploying apps with known bugs.

On asimilar note, mydemo licence is going to end soon and I have ordered thefull licence for the discounted compaq upgrade. As I don't have the .net version of visual studio the f90 compiler is no use to me - my cfv will suffice for the moment.As I am only currently interested in the array visualiser, will Ionly receivefuture upgrades to AV if I buy the upgrade of the compiler? Or will installing the most recent AV install kit upgrade the AV to the latest version and still recognise my licence to let me use it?

Once you have IVF w/AV installed, don't try installing the AV download kit. I think the install won't let you proceed in any case.

Intel releases updates to IVF (and AV) very frequently. In any given month there is usually a new update. I'll try to get this fix into the next update which should be available next week or the week after.

New releases come along once or year or so. The next planned release is 9.1 which will be going into beta soon.

If you want to use the Intel Fortran compiler, you can get Visual C++ .Net 2003 Standard Edition. You should be able to get it for less than $100.

Deje un comentario

Por favor inicie sesión para agregar un comentario. ¿No es socio? Únase ya