Closing ActiveX references correctly in Simple UI

Hi,
I am currently trying to modify the Simple UI provided with Teststand 2013 in order to access global station variables through LabVIEW. As a simple test, I am trying to access the LastUserName value. When I run the VI for the first time after opening LabVIEW, I get no error messages and the program runs as required. Stopping the VI execution returns no errors, but when I try to run the VI and run the Teststand sequence again, the execution stalls and I get a waiting status. I must then close the VI execution by killing all Teststand threads I believe the PropertyObjects are not released properly and I find the event structure quite puzzling to deal with.
My attempt at closing the references within the while loop looks like this :
The rest of the program is exactly as provided with Teststand 2013.
Any input on how to properly close the ActiveX references and retrieving station globals within LabVIEW would be much apreciated.
Thank you for your help,
Christian
Solved!
Go to Solution.

First of all, I would like to thank you for your answer.
I understand that repeatedly opening a reference inside the while loop does not represent a viable solution. This morning I found a very handy reference that explains how to pass data from the Teststand API through custom UI user messages. This allows a more elegant and robust way of handling data that is retrieved from Teststand. I'll use a custom event call back that will trigger on any custom message.
Here are the references ( which are IMO clear enough for someone with very little LabVIEW experience) :
http://www.ni.com/white-paper/4532/en/
https://decibel.ni.com/content/docs/DOC-21047
So far, I have been able to create a dummy Teststand sequence that sends a custom UI message containing the string ''Hello, world!''. The UI can accordingly retrieve the string and display it in a dialog box.
I still have to find a way to pass the data from the subVI to my UI. I am investigating the use of global variables, but there may be a better solution that I am not aware of. Any input on how to pass information between two active VIs would be much appreciated!
Christian

Similar Messages

Excel Get ActiveX References.vi and closing references -- grrr

I'm new to ActiveX stuff, but eager to learn!
The "grrr" in my Subject line is a reference to how I feel about LabVIEW's documentation from time to time. I'm a dinosaur who came from text-based programming, and did a fair amount of C coding, so sometimes with LabVIEW I'm left with this awful feeling in the pit of my stomach like, "Good grief! How much memory must LabVIEW be hogging up in the background when I use this vi?" or "What happens to those variables (wires) in that subVI when it completes but doesn't close? What are their statuses when I come back in the next time?" or "What if I put a lot of elements into that array the first time and then started from element zero the second time and just put in a few? What has happened with the memroy that was allocated when there were a lot of elements?"
Today I'm stewing about this "Excel Get ActiveX References.vi," and what happens to the "ActiveX references" it generates each time I call the subVI in which "Excel Get ActiveX References.vi" lives. I think that at least one of the "ActiveX references" it generates when I call it is of the type Excel._Application. Then there appears to be an Excel._Workbook, and others. You see, I've used "Excel Easy Report.vi" to put some data into an Excel spreadsheet, and I want to tell Excel to do a "Save" on the open spreadsheet. I think ActiveX is the (a) right way to do that, so I'm wading into the ActiveX fray... But this "Excel Get ActiveX References.vi" says in its help file, "Do not close ActiveX references opened with the Excel Get ActiveX References VI. References must remain open until the report is closed. Otherwise the error 3001 will occur." Well, these Excel workbooks that get created by my VI could well stay open until after my LabVIEW VI terminates!
So (finally), here are some of my quesitons:
1) When I go through my subVI once, pointing to one workbook, I'll get one set of references "created" or "opened" or whatever you call it when ActiveX references spring into existance. Now, when I exit the subVI, is it going to automatically try to "close" those ActiveX references? I don't suppose so, since subVI's stay in memory until the calling VI closes.
2) Now, I come back into my subVI a second time. New workbook gets created, so I get new references. Ok, fine. Uh oh! What happened to those old references? I suppose that if I didn't somehow save them off, I've probably lost the ability to get them back (maybe I'm wrong, but I don't need them back), but is LabVIEW going to "close" those old references (from previous times through the subVI) because I can't get to them anymore? Won't that cause the dreaded error 3001? If LabVIEW is not going to "close" them, what in tarnation happens to them (the old C programmer in me creeping back out)?? Now it's some oddball, orphaned reference, floating out there, hogging memory, waiting to make something crash intermittently and be a debugging nightmare?
3) Now, here's the real scary one. I think I might dodge the "error 3001" bullet in questions 1) and 2), but now let's say the user closes my LabVIEW application while Excel is still open. All those workbooks are still open. Presumably, all those ActiveX references I was not supposed to close are still open. I really hope that LabVIEW is decent enough to close/erase/delete/blow-away (whatever the right word is) all those ActiveX references which were opened/created by "Excel Get ActiveX References.vi" when my program terminates. But, oh no! Won't the error 3001 come along then? I suppose I can just dump it in the shutdown error handling.
Well, thanks for reading my novel. I don't know what can be done with LabVIEW documentation to make it more satisfying to folks like me, but perhaps someone can weigh in on all my ActiveX questions here.
Thank you in advance,
Steve Brady
Solved!
Go to Solution.

You need to close EVERY ActiveX reference you open. If you don't you'll end up with some Excel processes running even after LabVIEW exits. You can see them in Task Manager.
I, personally, don't like the LabVIEW Report Generation Tool Kit for working with Excel. I don't think it's flexible enough. I have a growing library of VIs that I've written that open, manipulate, and close Excel. Some references I pass from VI to VI and some I close right after I use them. It all depends on what I'm doing. If I want to enter read or write data from/to a certain range I'll get the range reference, read or write the data, then close it right away because I have no use for it any more. On the other hand, when I open Excel or a Workbook I keep the reference until I'm done, which could be later in the program.
1) When I go through my subVI once, pointing to one workbook, I'll get one set of references "created" or "opened" or whatever you call it when ActiveX references spring into existence. Now, when I exit the subVI, is it going to automatically try to "close" those ActiveX references? I don't suppose so, since subVI's stay in memory until the calling VI closes.
2) Now, I come back into my subVI a second time. New workbook gets created, so I get new references. Ok, fine. Uh oh! What happened to those old references? I suppose that if I didn't somehow save them off, I've probably lost the ability to get them back (maybe I'm wrong, but I don't need them back), but is LabVIEW going to "close" those old references (from previous times through the subVI) because I can't get to them anymore? Won't that cause the dreaded error 3001? If LabVIEW is not going to "close" them, what in tarnation happens to them (the old C programmer in me creeping back out)?? Now it's some oddball, orphaned reference, floating out there, hogging memory, waiting to make something crash intermittently and be a debugging nightmare?
3) Now, here's the real scary one. I think I might dodge the "error 3001" bullet in questions 1) and 2), but now let's say the user closes my LabVIEW application while Excel is still open. All those workbooks are still open. Presumably, all those ActiveX references I was not supposed to close are still open. I really hope that LabVIEW is decent enough to close/erase/delete/blow-away (whatever the right word is) all those ActiveX references which were opened/created by "Excel Get ActiveX References.vi" when my program terminates. But, oh no! Won't the error 3001 come along then? I suppose I can just dump it in the shutdown error handling.
1) No, LabVIEW will NOT close those references. You need to make sure that happens.
2) You can save the references in a functional global or use a class but if you're not going to save them close them as soon as you're done with them.
3) Your user should not be able to close your LabVIEW application without it going through the shutdown routine you've created for your program. The ABORT button should never be exposed to the user and you should capture and discard the panel close event so your program ALWAYS shuts down is an orderly fashion. If you don't you will have fragments of Excel hanging around in your operating system and will have to kill those processes using Task Manager. That should only be a problem during development, not once deployed.
I used to program in C and Assembly many moons ago. You should have seen my first LabVIEW code. I go back and look at it just so I can see how far I've come in the last 12 years. I feel your pain.
Kelly Bersch
Certified LabVIEW Developer
Kudos are always welcome

Opening/Closing Queue Reference By Name

I'm curious if opening and closing a queue reference to put information onto the queue, using the queue name -> obtain queue -> enqueue -> release queue(Non Force) is problematic. I thought i saw a thread a long time ago that opening/closing a reference to a queue over and over could lead to a memory leak, even if the original queue never was released. Obviously, i'm ignoring the general pass the wire(by value) correct labview way.
Instead of opening/closing using the queue name i could also wrap the queue reference in a FG after originally creating it and work on the reference that way. Ignoring the "right way to do it" are there still downsides, other than programing correctly, to open/closing queue reference's in this fashion such as memory leaks.

PaulG. wrote:
I have never heard of any unwanted consequences of repeatedly opening and closing any reference. The trick is to make sure a reference gets closed when no longer needed. I don't see any reason not to implement queues the ways you describe. I've done all three and haven't had any issues that I know of. If opening and closing a queue reference repeatedly caused a memory leak that would be considered a bug.
I have to disagree here. A couple of years ago I was using a DAQmx Write with "autostart" option set to TRUE in a loop (ca. 100ms timing) to constantly make sure, that in application standby my Digital Outputs kept the values they ought to have. This reproducibly caused a blue screen on Windows after 6 hours of the program running in standby. As it turned out, LabVIEW was using a new reference to the task for every call of the Write, because with autostart set to TRUE it had to create the task beforehand and close it afterwards. After the mentioned peroiod of time, LabVIEW ran out of reference numbers, as the support explained to me.
Of course, even LabVIEW Help says to avoid using autostart=TRUE with DAQmx VIs in a loop, but only because of the overhead the repeated Create and Clear is consuming. Naturally, I have learned that the hard way now.
So - Create the reference once, use that same reference all the time (FG is fine, I think - I use this method for obtaining my logfile reference all over the place!) and close it only, when you don't really need it anymore.

How to know what ActiveX references are still open

Okay, so I'm about the millionth person to post about this topic, but I feel like I know what I should be doing, but have hit a wall. I have read through pretty much everything I could find in the forums about references and ActiveX.
I am communicating with Excel via ActiveX, and everything works seemlessly, until I realized that if the user closes the Excel sheet (via an "exit" button on my FP), the "EXCEL.exe" process is still running. I've read enough to know that this probably points to a reference that I have not closed.
Problem is, I have poured over my code, and as far as I can tell, I have closed every reference, in the opposite order it was opened (as I read to do in a post earlier).
Aside from casting references to int's to see what is still considered "active" (as I mentioned earlier, all the ones I can find are closed, so this doesn't help me), is there a way to determine which ActiveX references are still open?
Even a way outside of LV? A Microsoft utility even or ...well anything! This is very annoying, and I know it should be quick and easy, I just have to know what is remaining open.
Or, am I missing something else that might be keeping EXCEL.exe running? (yes, I have an application quit and close the application reference)
Thanks for any help

Hi Will,
As you said it yourself closing the same number of references as you open and using Application Quit should be enough to close down Excel.exe.
Did you run your code in highlight execution to see how the behavior of your program changes when you hit the "Exit" button on your Front Panel?
If you can post the minimum amount of code that reproduces the error, I will be more than happy to take a look at it.
Best regards,
Message Edited by Kalin T on 12-07-2006 03:11 PM
Kalin T.
National Instruments
Attachments:
activex_excel.jpg ‏16 KB

Update ActiveX References Error

There MUST be a simple way to update ActiveX References when a third party library has been updated to a new version.
I had made up several VI's that passed the ActiveX Class Refnum around. This refnum was generated by right-clicking on a standard Automation Refnum and selecting the third party Class - (called DebenuPDFLibraryAX0913.IPDFLibrary).
I then upgraded this Third party software and changed the Refnum to the new version (DebenuPDFLibraryAX0915.IPDFLibrary) and it broke all the links with the existing VI's - fair enough.
So I tried just using the generic Automation Refnum to pass the reference around, but that doesn't recognise any of the Methods/Properties of the Class in each VI.
It seems I'm caught in a Catch-22. If I use the specific ActiveX Class version to pass around all my VI's then when I upgrade the software I have to change ALL the Automation Refnums to the new Class Value. If I try and make it generic it doesn't recognise anything in the Class.
How on earth can I just upgrade one VI with the new ActiveX class and have this new reference work for all the VI's I created in my "LabVIEW library".
The links below were in 2002 and 2006 and seem to suggest that one has to MANUALLY go around updating ALL Refnum's. I really hope there is a better way of doing this now.
http://forums.ni.com/t5/LabVIEW/How-do-I-update-my-ActiveX-controls-without-breaking-existing/m-p/53...
http://forums.ni.com/t5/LabVIEW/How-do-I-quickly-update-the-ActiveX-automation-references-in-my/m-p/...
Chris

Hi ChrisReed,
Unfortunately there is not a simple way to update the ActiveX References. Since you are updating the library, every reference would also need to be updated manually. There is not a tool to do this currently, but it may be worth creating a post on the LabVIEW Idea Exchange! We are always looking for new ideas to make LabVIEW an even better experience for our users. I have linked the Idea Exchange below:
LabVIEW Idea Exchange
| Zach J. | Applications Engineer | National Instruments |

Obtaining activex reference from activex container

I have a VI with an embedded MediaPlayer activex object inside an activex container. Additionally, I have a seperately run VI which I want to be able to control the MediaPlayer obejct in the first VI. These VIs are opened seperately, so I cannot pass information directly from one to another (i.e., I can't directly pass the MediaPlayer activex reference to the second VI directly). Therefore, the second VI obtains a reference to the activex container object by searching the first VI's controls and filtering by label. I can typecast the control reference to the level of activex container, but from there I have no way of obtaining a reference to the object embedded in it. Is there are way to do this? The "To more specific class" function does not accept activex references for typecasting, and the automation open does not accept activex container references. I've searched through the forums, and while there is plenty on activex references and containers, there doesn't seem to be anything that addresses my issue.

I'm not 100% about whether this will work, but give it a try. Once you have a reference to the container, use the 'Value' property. This will give you a variant. From here you can use Variant to Data, connect a MediaPlayer constant reference to the type input and you should get the correct reference out.
Also, you could simply get a reference to the VI with the ActiveX control and use the method 'Control Value: Get[Variant]' to get the value of the control instead of getting a list of all the controls and searching for the one you want.

Get Sequence context from ActiveX reference

Hello,
I am passing to MFC DLL ActiveX reference to freshly created new execution. In examples it is shown how to pass "ThisContext" to DLL (struct IDispatch *seqContextDisp) but i need something like :
- create new execution, save ActiveX reference in local variable
- pass reference to DLL
- in DLL get from reference sequence context and perform some operations (get/set vaiables, etc.)
Thanks.

I'm not sure I fully understand the question but I'll take a stab at it anyways. First if you want to have seq context of the new execution; review my sample seq file I sent along. In this seq file you can pass seq context of the new execution to a dll in either seq/execution.
If this is a simple "C" type question the prototype/code would look something like the .cpp file I attached.
My stuff may have a couple different parameters!
If I misunderstoo the question you might want to send me what you got so far... It might be eaiser for me to see what you are tyring to do and I can finish an example for you.
[email protected]
Attachments:
Sequence_File2.seq ‏16 KB
handleexports.cpp ‏9 KB

If an application includes ActiveX references from Excel, should MS Office be installed on the run-time PC?

There are many threads regarding usage of MS office with LV, but I was not able to find the answer to the following question. I hope somebody can help or point me to a useful thread.
I have an excel template file and would like to create new reports each time from it. There are a couple of solutions for this problem which are fine. But, at the end, I am going to build an application and install it on an industrial PC which does not have MS office installed. The question is if the application works on the target machine as well.
I am specifically pointing to the solution in here which uses ActiveX reference to Excel._Application. Any chance that this solution or any similar one works on my target PC?
If you wonder why I want excel reports on a machine that does not have MS Office, I should say that the reports are just stored somewhere on the disk to be transferred later to headquarters let say!
Developing machine: Win7, LV8.6 Pro + Report generation toolkit
Target machine: WinXP SP3, LV run-time engine
Thanks in advance!
Soroush
Solved!
Go to Solution.

You need to have Office installed on the computer that is running the LabVIEW application. It is the Office applications that provide ActiveX functionality to the Report Generation Toolkit. Without them, LabVIEW has nothing to interface to.
http://digital.ni.com/public.nsf/allkb/02E339E26484F30186256E920061FBD9
Now is the right time to use %^<%Y-%m-%dT%H:%M:%S%3uZ>T
If you don't hate time zones, you're not a real programmer.
"You are what you don't automate"
Inplaceness is synonymous with insidiousness

Passing an ActiveX reference from TestStand to Labview

How can I pass and ActiveX reference (for a dll) created and used in a TestStand sequence (under Locals) to a VI running within that sequence so that I can then call the same instance of the dll from Labview?
(I know this isn't the best approach to programming but I'm more interested in proving the point than anything else)
Cheers
Dan

Here's what I think you are tyring to do. Within your sequence, instantiate an object from an ActiveX DLL, storing a reference to it within a TS variable. Then, within a VI called by this sequence, call a method of the intantiated object.
To do this, when specifying your module on your LV step you must check the Sequence Context ActiveX Pointer check box. In the called VI you must have the a Sequence Context control on your front panel and have it wired to your connector pane along with a TestData cluster control and a LV Error Out cluster control.
Within the VI you use an invoke node to invoke the AsPropertyObject method on the SequenceContext (Make sure you use the ActiveX close function on this new reference when you are done with it.). Use another invoke node to call GetValInterface method on the sequence context property object reference (you could probably also use the GetValIDispatch method. See the help). For this invoke node you will want to use a lookupstring that reference the variable, relative to yo sequence context, in which you stored the refernce to the instantiated object in your sequence file. This will return a variant reference. You must convert this reference to a LV reference using the "To G Data" function in the ActiveX palette. The "To G Data" function requires a type input. You will need an ActiveX Automation Refnum control as the input to this (see ActiveX control palette). You will need to right click on this automation refnum control and browse the ActiveX automation server until you find the DLL ActiveX server from which you instantiated your object within your sequence. Once selected, also select the object that you instantiated. The "To G Data" function will then give you a reference to you object on which you can happily used in your desired manner. Make sure to close this reference with an ActiveX Automation close function when you are done with it.
I would definitely clean this up with a subVI to perhaps generalize the solution.

Do I need to close ActiveX references?

Hi,
I am developing a library of VIs that use ActiveX to control APWin (for Audio Precision System Two) with LabVIEW where both are running on the same PC and I am wondering if I need to close ActiveX refnums when I'm finished along a particular heirarchy level. The context help says that LV closes references when they're no longer needed but is it bad practice to leave them open? Can not closing refnums potentially cause problems? See attached picture for an example.
Thanks,
Sara
Attachments:
close_ref.JPG ‏46 KB

Sara2004 wrote:
> Thanks for your response. This is good to know. I'm assuming the same
> is true for MSWord and MSExcel report refnums...is this a correct
> assumption?
You should generally close any refnum. LabVIEW 7 does have improvements
to its own refnums (App and VI refnums, Control refnums) which does not
require to close them anymore but doing so will definitly not hurt.
For Active X refnums, in the best case they just use up memory until you
close the entire application or the LabVIEW development system. In the
worst case the system can crash when you close the executable or LabVIEW
due to the Active X component stumbling over left open object references
when Windows forces those objects to be closed on behalve of the leaving
execu
table.
Rolf Kalbermatter
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Can I browse all ActiveX references in memory?

Hi,
Out of curiosity, is there a way to browse all of the ActiveX objects
in memory? Or at least the ones initialized from LV? If you
have a ton of objects floating around out there, it would be handy to
have such a function to help you close them when you're done with them.
Thanks,
Nick
"You keep using that word. I do not think it means what you think it means." - Inigo Montoya

Hi Nick,
That's a valid suggestion for the LabVIEW developers (post it using the "feedback" link on ni.com/contact), but I'm afraid that it would invite customers to mess up things by not keeping references in a short leash and closing in the right order when done.
In case you want the closest to this kind of feature, try the Request Deallocation function and place it inside the VI that holds the references. When that VI finishes and returns to the caller, all unused memory will be deallocated.
- Philip Courtois, Thinkbot Solutions

Closing control[] reference

If I have a main VI that calls sub-VI's, and I pass the control[] refereces of the controls in the main VI to the sub-VI. Should I use a for loop to close the control[] reference? And should I close the control[] referece in the main VI or the sub-VI?

My understanding of what you are doing is building an array of the control references in the main vi to pass to the sub-vis. Is this correct? If so, why not bundle the references instead? This way you could easily pull out the required reference by name.
Aside from that, if you are passing references to the front panel objects you shouldn't need to close them at all. The following links should be useful in helping you to understand when to close references:
http://exchange.ni.com/servlet/ProcessRequest?RHIVEID=101&RPAGEID=135&HOID=506500000008000000834C0000&UCATEGORY_0=_49_%24_6_&UCATEGORY_S=0&USEARCHCONTEXT_QUESTION_0=closing+references&USEARCHCONTEXT_QUESTION_S=0
http://www.ni.com/devzone/lvzone/dr_vi_archived4.htm
Hope that helps.
John

Why does opening and closing FPGA references increase Windows XP handles by 3?

Hello.
We run a test system here that uses TestStand to communicate
to a number of Labview VI modules which in turn communicates to a
PXI-7833R FPGA. Everything has been working fine except after a long time running Labview would get an out of memory error. I discovered
after a particular VI was run 100,000 times, the number of handles in Windows XP Task
Manager grew to about 370,000. The number of threads and processes remains stable and normal. Closing Labview removes all the excessive handles.
I tried an experiment to create a standalone VI (ie: no TestStand) which simply opens the FPGA VI reference then closes the reference. This is repeated 4 times in the same VI. The number of handles in Windows XP Task
Manager increased by 12 each time the VI was run. No errors. This indicates closing the FPGA reference might not be working.
Why does this happen? Is there a way to avoid it? The version of Labview is 8.5.1.
Appreciate any help here. Thanks.
-Dave

could be related to this known issue--
FPGA FIFO reset behavior—When you use an FPGA target
emulator, FPGA FIFOs reset when the VI is stopped and then started
again. When you use an FPGA target with Interactive Front Panel
Communication, FPGA FIFOs do not reset when the FPGA VI is stopped and
then started again. To reset the FIFO, right-click the FPGA target in
the Project Explorer window and select Download
from the shortcut menu. When you control an FPGA VI using Programmatic
FPGA Interface Communication, use the Close FPGA VI Reference function
with the Close and Reset shortcut menu option selected or the Invoke Method with the Reset method selected to reset FPGA FIFOs
see Knowledgebase
Also remeber to load the FPGA Read/Write VI's dynamically from testStand and dump them after. Thechange to the data type causes the vi to need to recompile so it can't stay in memory if you need different types of data.
Message Edited by Jeff Bohrer on 10-27-2009 02:21 PM
Jeff

How do I get an ActiveX Reference to sheet that is already open.

I need to get a reference to an Excel sheet to write some data to. The problem is the workbook is not opened by ActiveX and I can't seem to find the right combination of Methods and Properties to get the reference.
This is on WinXP, Office XP and LabVIEW 6.1.
Thanks
Ed
Ed Dickens - Certified LabVIEW Architect - DISTek Integration, Inc. - NI Certified Alliance Partner
Using the Abort button to stop your VI is like using a tree to stop your car. It works, but there may be consequences.

Sorry, I was rushed for time.
Here's what I did.
Ed
Ed Dickens - Certified LabVIEW Architect - DISTek Integration, Inc. - NI Certified Alliance Partner
Using the Abort button to stop your VI is like using a tree to stop your car. It works, but there may be consequences.
Attachments:
Turn_Off_Zeroing.vi ‏59 KB

Shockwave Flash ActiveX reference?

Hello. I am trying to embed the Shockwave Flash ActiveX
object into my C++ application. I am having a hard time finding the
official reference documentation for the interfaces. Does anyone
have a link on hand?
Thank you for your help!

Hola samsara 1970:
Pues al parecer o tienes desactivado el control active x del
sockwave Flash
Player o bien tienes activado el bloqueo de ventanas
emergentes o pop us,
pero entonces te saldría también la linea amarilla
superior que te dice que
"internet explorer ha bloqueado en aras de su seguridad....",
por lo que
supongo que será solamente la primera de las opciones.
Para solucionarla vete en Internet Explorer a
Herramientas/Administrar
Complementos y asegúrate de que en el desplegable te
dice: "Mostrar todos
los complementos actualmente instalados en Microsoft Internet
Explorer",
tras lo cual te mostrará la lista de plugins del
navegador de internet.
En ésa lista eliges el Shockwave Flash Object y, debajo,
en configuración,
activas la casilla habilitar.
That's all.
Salu2
`8¬}
Juan Muro
"samsara1970" <[email protected]>
escribió en el mensaje
news:ejiu02$84v$[email protected]..
> Hola: después de dar mil vueltas por la web
buscando una solución y no
> encontrarla es que decidí pedir ayuda en este foro.
El tema es que quiero
> instalar un programa, y al darle doble click al exe,
aparece un cartelillo
> de
> los grises de ERROR con la única opción de
aceptas que dice "unable to
> register
> shockwave flash activex control". Quisiera saber que es
lo que puedo y
> tengo
> que hacer. Gracias.
> Mi sitema operativo es Windows xp profesional, service
pack 2. Tengo
> instalados los shockwave y flash player, las
últimas versiones. Espero que
> alguien me pueda ayudar. Desde ya muchas gracias. Atte.
Valeria Echegaray
>
>

Closing ActiveX references correctly in Simple UI

Similar Messages

Maybe you are looking for