Results 1 to 23 of 23

Thread: Events – How They Work, CPU Intensive

  1. #1

    Thread Starter
    Fanatic Member
    Join Date
    Nov 2014
    Posts
    553

    Events – How They Work, CPU Intensive

    I am always looking for new ways to speed up code, but I keep running into the same problem, I don’t know enough about VB.

    I tried searching the web for details on VB events but that was a bust, some say delegates are used while others say not. Some go down a vague road with listeners and senders but never provide anything tangible.

    I have a project with a dozen or so UserControls, rather involved with more events then I care to count, Ok I counted 87 in all. So far I have confirmed that only 8 of these events are used. As for the others, nobody is responding or ‘listening’ to them so shouldn’t I be able to remove the ones not in use?

    Again I don’t know how the event mechanism works in VB, but there must be some overhead in sending / raising all of these events?

    Or is there perhaps a compiler optimization that would pull out the events that don’t have a matching ‘listener’?

  2. #2
    PowerPoster
    Join Date
    Feb 2012
    Location
    West Virginia
    Posts
    13,281

    Re: Events – How They Work, CPU Intensive

    As far as I know those events are in the runtime dll. Obviously you should not have any code in your project for the events you are not using and if you do then you can remove them by simply removing the code.
    For example if you double click on a textbox that has no code behind it yet you will get this in your code window
    Code:
    Private Sub Text1_Change()
    
    End Sub
    If you have no plans to use that event then you can remove that code. Is that what you are talking bout?

  3. #3
    Hyperactive Member
    Join Date
    Jul 2013
    Posts
    374

    Re: Events – How They Work, CPU Intensive

    Quote Originally Posted by stuck-n-past View Post
    I am always looking for new ways to speed up code, but I keep running into the same problem, I don’t know enough about VB.

    I tried searching the web for details on VB events but that was a bust, some say delegates are used while others say not. Some go down a vague road with listeners and senders but never provide anything tangible.

    I have a project with a dozen or so UserControls, rather involved with more events then I care to count, Ok I counted 87 in all. So far I have confirmed that only 8 of these events are used. As for the others, nobody is responding or ‘listening’ to them so shouldn’t I be able to remove the ones not in use?

    Again I don’t know how the event mechanism works in VB, but there must be some overhead in sending / raising all of these events?

    Or is there perhaps a compiler optimization that would pull out the events that don’t have a matching ‘listener’?
    I'm a noob with VB, but this is how I see it: if the code for an event is generated them that event will be called even if it does nothing, and "eats" processor time with stack push/pop. So, speed wise, it's better to not define it.

  4. #4

    Thread Starter
    Fanatic Member
    Join Date
    Nov 2014
    Posts
    553

    Re: Events – How They Work, CPU Intensive


    If you have no plans to use that event then you can remove that code. Is that what you are talking bout?
    Yes an no, there is no code on the program side responding to the Raise Event statements in the UserControls. It looks as if the UserControls all came from a template that has all of the standard events handled such as KeyDown, KeyPress, KeyUp, MouseMove etc. The program that make use of the UserControls don't have any corresponding routines to handle the events so I was just going to remove the Raise Event statements from the UserControls that aren't being responded to.

    There are sections in the UserControls with cookie cutter like comments instructing the programmer not to remove. So I was not sure if some of the Rasia Events were like place holders that were required for something down the road I was not aware of.
    Last edited by stuck-n-past; Apr 14th, 2015 at 04:30 PM.

  5. #5
    Default Member Bonnie West's Avatar
    Join Date
    Jun 2012
    Location
    InIDE
    Posts
    4,057

    Re: Events – How They Work, CPU Intensive

    Quote Originally Posted by stuck-n-past View Post
    I am always looking for new ways to speed up code, but I keep running into the same problem, I don’t know enough about VB.
    You might find Aivosto's Resources for developers to be very helpful.

    Quote Originally Posted by stuck-n-past View Post
    I tried searching the web for details on VB events but that was a bust, ...
    Here's a few in-depth articles about COM Events:

    On Local Error Resume Next: If Not Empty Is Nothing Then Do While Null: ReDim i(True To False) As Currency: Loop: Else Debug.Assert CCur(CLng(CInt(CBool(False Imp True Xor False Eqv True)))): Stop: On Local Error GoTo 0
    Declare Sub CrashVB Lib "msvbvm60" (Optional DontPassMe As Any)

  6. #6
    PowerPoster
    Join Date
    Jul 2010
    Location
    NYC
    Posts
    2,569

    Re: Events – How They Work, CPU Intensive

    *If* you're sure your project and no other project using that file has code responding, it's perfectly safe to comment out the RaiseEvent lines in user controls (wouldn't recommend deleting them in case you or anyone using your code might need it someday, even if unforseen, but any other line whatsoever will require more analysis before determining whether it's ok to remove. Especially if it's something like returning a WndProc as non-zero by default; you wouldn't want to remove that entire thing and return zero in most cases.

    As to performance, I'd sincerely doubt there's going to be statistically significant improvement as the % of cpu time it takes up is pretty close to zero.

    Doing your own implement-as-needed version of complex user controls would help- take the excellent common controls by krool, they're great, but they're massive, full implementations. Instead, I don't use a user control at all and just use CreateWindowEx and implement whatever features are needed by my project instead of thousands and thousands of lines mucking about needlessly in the depths of hooking and IOle... unstable stuff.

    ps- If you're REALLY into performance, VBSpeed is a fun site.

  7. #7
    VB-aholic & Lovin' It LaVolpe's Avatar
    Join Date
    Oct 2007
    Location
    Beside Waldo
    Posts
    19,479

    Re: Events – How They Work, CPU Intensive

    Agree completely with fafalone. What event could possibly be cpu intensive? The only thing I can think of is if some recursive action is going on while also raising events, i.e., control size change triggered & inside that routine, it's raising an event while also resizing itself, forcing yet another change being triggered. Why even leave a RaiseEvent active if you are never going to use it -- rem it out
    Insomnia is just a byproduct of, "It can't be done"

    Classics Enthusiast? Here's my 1969 Mustang Mach I Fastback. Her sister '67 Coupe has been adopted

    Newbie? Novice? Bored? Spend a few minutes browsing the FAQ section of the forum.
    Read the HitchHiker's Guide to Getting Help on the Forums.
    Here is the list of TAGs you can use to format your posts
    Here are VB6 Help Files online


    {Alpha Image Control} {Memory Leak FAQ} {Unicode Open/Save Dialog} {Resource Image Viewer/Extractor}
    {VB and DPI Tutorial} {Manifest Creator} {UserControl Button Template} {stdPicture Render Usage}

  8. #8
    Hyperactive Member
    Join Date
    Jul 2013
    Posts
    374

    Re: Events – How They Work, CPU Intensive

    Quote Originally Posted by LaVolpe View Post
    Agree completely with fafalone. What event could possibly be cpu intensive? The only thing I can think of is if some recursive action is going on while also raising events, i.e., control size change triggered & inside that routine, it's raising an event while also resizing itself, forcing yet another change being triggered. Why even leave a RaiseEvent active if you are never going to use it -- rem it out
    I will take the ride to clarify myself about this, if the OP doesn't mind.
    I only use VB6 to wrap a few components to simplify their use in my environment. All I have to do is to add a reference to the needed component, define all possible events, generate the respective methods, and from there call "RaiseEvent" to use it from my side. But usually I only need some of them.
    Is this a good practice? I mean, If I only need MouseClick does it make sense to define MouseDown, MouseUp and MouseClick? Does the component send the event if the respective event/method is not defined in VB?

  9. #9
    PowerPoster
    Join Date
    Feb 2006
    Posts
    21,437

    Re: Events – How They Work, CPU Intensive

    Microsoft ensured that web searches would return a great deal of irrelevant junk by trying to palm VFred off as VB. So a lot of hits you'll get are completely false hits since search engines tend to index VB, VB.Net, VB5, VB6, etc. as all "VB." For example just move on when BS about "delegates" is present.


    The point of most classes, including UserControls and even some custom dialog Forms is at least in part reuse.

    If you have a given program that uses one of these but doesn't need all of the events you could trim them out. You could also trim out unused properties, methods, enums, etc.

    However...

    Now you have a new maintenance burden. Instead of one to mantain you have n of them to maintain, at least one separate copy for each set of customizations.

    As far as overhead goes, events can have some overhead. As far as I can tell they use IDispatch (late) binding, and of course large String parameters passed ByVal must be copied. But in most cases the penalty for not having a sink for each one is minimal.

    You also have the option of COM callbacks as an alternative when performance is an issue. This can use vtable (early) binding, which can be quicker though the ByVal String issue doesn't go away.

    Maybe take a look through Asynchronous Call-Backs and Events in the manual.
    Last edited by dilettante; Apr 14th, 2015 at 11:04 PM.

  10. #10
    Frenzied Member
    Join Date
    Aug 2010
    Location
    Canada
    Posts
    1,614

    Re: Events – How They Work, CPU Intensive

    If your unused events are demonstrably causing a performance problem, and you've got the source code for the UserControl, instead of carving away all your events for one project (and now having a maintenance burden) you could do one on the following:

    • Add one new Disable*Event boolean property per event that when set to True will prevent the event from firing (by wrapping your RaiseEvent calls in an IF block testing the boolean).
    • Add an EventFlags property that lets you set a bitmask to enable/disable a bunch of properties in one go (you could even have common bitmasks defined as Enums to make life easier). This is more compact, but more abstruse than the previous idea. You would then wrap all your raise event calls with tests for the appropriate bit in your flag variable.


    With either of the above approaches, different control hosts can decide what events they want to have raised.

  11. #11
    Hyperactive Member
    Join Date
    Jul 2013
    Posts
    374

    Re: Events – How They Work, CPU Intensive

    Thanks. I think I'm enlighten now

  12. #12

    Thread Starter
    Fanatic Member
    Join Date
    Nov 2014
    Posts
    553

    Re: Events – How They Work, CPU Intensive

    Thanks so much for all the reference links, I like nothing better then finding helpful sites with good material to read and learning how things work behind the scenes.

    As for search engines, they are getting so packed with irrelevant information it’s getting more difficult to weed out valid results from the bogus ones. With all my many searches, I can’t believe that I have never before come across VBSpeed.

    I appreciate all of the help and suggestions regarding the unused Raise Events and I am going in the direction of commenting them out. In this particular situation I don’t have to worry about versions or maintenance issues, as this is such a specific application I can’t foresee any reuse of the UserControls. Of course now that I said that I’m gonna get burned.

    In the early moon rocket days of programming, you could spend an entire career saving a byte of memory here and there, or pulling out your hair searching for a way to save a millisecond or two. In some ways I feel that much has been lost in the ‘art’ of programming. Today the knee jerk reaction to code running slow is to throw more money at the problem with bigger faster computers. I have amazed myself with the increases in speed that can be accomplished through efficient coding practices.

    I am heading off to read up on COM Event Handling – Thanks.

  13. #13

    Thread Starter
    Fanatic Member
    Join Date
    Nov 2014
    Posts
    553

    Re: Events – How They Work, CPU Intensive

    After reading up on COM Events from the links provided my brain has turned to mush. If I understand things properly there shouldn’t be much of a performance hit in leaving Raise Events in the UserControls.

    Once VB knows it has an event handler \ listener \ sink or whatever, it queries the COM object with some handshaking. First to make sure the interface exists, then VB sends a pointer with the address of the sink back to the COM object. Therefore if VB has no corresponding sink to a UserControl’s Raise Event, then the COM object has no address to even attempt the call to the handler and must pass over the request.

    With the RaiseEvent statement being an intrinsic function I would doubt their even being a calling convention push \ pop overhead. The only overhead would likely be a conditional statement on the COM side checking to see if it has a valid address to call. Either that or as with so many times in the past I have it completely wrong.

  14. #14
    Hyperactive Member
    Join Date
    Jul 2013
    Posts
    374

    Re: Events – How They Work, CPU Intensive

    Quote Originally Posted by stuck-n-past View Post
    With the RaiseEvent statement being an intrinsic function I would doubt their even being a calling convention push \ pop overhead. The only overhead would likely be a conditional statement on the COM side checking to see if it has a valid address to call. Either that or as with so many times in the past I have it completely wrong.
    My initial doubt was not about the RaiseEvent overhead, but the MyControl_MyEvent function declaration overhead. In this case I think the function is always called, and a push/pop exist.

  15. #15

    Thread Starter
    Fanatic Member
    Join Date
    Nov 2014
    Posts
    553

    Re: Events – How They Work, CPU Intensive

    It's quite possible the call is made I was just putting myself in the drivers seat thinking if I were the person coding the COM - Client interaction, I would first check for a valid address to the sink before I performed any processing. But then I always code leaning towards best performance.

  16. #16
    PowerPoster
    Join Date
    Jun 2013
    Posts
    4,930

    Re: Events – How They Work, CPU Intensive

    Quote Originally Posted by stuck-n-past View Post
    Once VB knows it has an event handler \ listener \ sink or whatever, it queries the COM object with some handshaking.
    Not directly - there's always a "middle-man" involved (a separate Class-Instance which is instantiated by the 'COM object' (the Event-Server).

    And since COM supports "multiple SubScribers" (for each Event a COM-Server has to offer) - and because
    many COM-Servers expose more than one Event on their Interface(s), there's quite a lot of "connection-
    information" which has to be managed.

    This snippet from the MSDN-Docu describes it quite nicely:

    The IConnectionPointContainer interface indicates the existence of the outgoing interfaces. It provides access to an enumerator sub-object with the IEnumConnectionPoints interface. It also provides a connection point sub-object with the IConnectionPoint interface. The IConnectionPoint interface provides access to an enumerator sub-object with the IEnumConnections interface.

    Each connection point is a separate sub-object to avoid circular reference counting problems.
    So, to sum it up in more VBish colored terms - A COM-Object (a COM-Server), which offers outgoing Events,
    implements IConnectionPointContainer - in case QueryInterface says, that a given COM-Object doesn't
    support this Interface, then it doesn't offer any Events.

    So, the whole thing is more or less "build-up" (and contained) in the Event-Server-Object, and
    "Sub-Objects" are created for *each* Event (aka IConnectionPoint) a Client-Subscriber requests a connection to.

    Hierarchy:
    IConnectionPointContainer (provided and implemented by the Event-Serving COM-Object)
    ....IEnumConnectionPoints (listing all the Events the COM-Server has to offer)
    ........IConnectionPoint (a separate Class-Instance, one for each concrete existing Event)
    ............IEnumConnections (each single Event can be delivered to "multiple SubScribers" - each of those SubScriber-Clients having its own Sink defined)


    Quote Originally Posted by stuck-n-past View Post
    First to make sure the interface exists, then VB sends a pointer with the address of the sink back to the COM object. Therefore if VB has no corresponding sink to a UserControl’s Raise Event, then the COM object has no address to even attempt the call to the handler and must pass over the request.

    With the RaiseEvent statement being an intrinsic function I would doubt their even being a calling convention push \ pop overhead. The only overhead would likely be a conditional statement on the COM side checking to see if it has a valid address to call. Either that or as with so many times in the past I have it completely wrong.
    As you see from the Hierarchy-List above, what happens in case of a RaiseEvent-Call
    will need a bit more efforts than a simple conditional-check.

    The MSDN-citation states, that IEnumConnectionPoints is a separate "enumerator-SubObject" -
    and even RaiseEvent itself is (in all likelyhood) already the first FunctionCall, followed by a
    Method-call (second function-call) against the ConnectionPoints-Enumerator-Object,
    to get the Info, if there are any SubScribers registered (for the EventName or -ID in question),
    in one of the IConnectionPoints.

    If there are no SubScribers on a given Event (IConnectionPoint-Instance) then the RaiseEvent-call
    will "return early" of course.

    But even in that "best case", there's at least those two function-calls to perform, any time
    the code reaches a RaiseEvent-statement (and that's not *that* much overhead, but overhead it is).

    And that this check has to be performed "any single time" is due to the fact, that with COM -
    the potential Event-Subscribers can (at Runtime) "pop-up out of the underwood" any moment.

    So, yeah - one can write a small test for that oneself, to measure the time it takes, to perform
    two nested function-calls (or alternatively measure the performance of the RaiseEvent-statement
    directly) - ... ah well, it's not that hard, did it now:

    This code here into a Class (named Class1) in a StdExe-Project.
    Code:
    Option Explicit
    
    Event TestEvent(P1, P2)
     
    Public Sub RunTest()
    Dim i, T
    Const n = 10000000 '10 Mio calls
      T = Timer
        For i = 1 To n
          RaiseEvent TestEvent(i, T)
        Next
      Form1.Print "RaiseEvent:", Format((Timer - T) / n * 10 ^ 9, "0ns")
      
      T = Timer
        For i = 1 To n
          SimulatedRaiseEvent i, T
        Next
      Form1.Print "Simulation:", Format((Timer - T) / n * 10 ^ 9, "0ns")
    End Sub
    
    Private Sub SimulatedRaiseEvent(P1, P2)
      If CheckForSubscriber(P1, P2) Then Exit Sub
    End Sub
    Private Function CheckForSubscriber(P1, P2) As Boolean
      CheckForSubscriber = (P1 <> P2) 'just to simulate a simple comparison at the second call-level
    End Function
    And this code into Form1.
    Code:
    Option Explicit
    
    Private WithEvents C1 As Class1
    
    Private Sub Form_Load()
      Set C1 = New Class1
    End Sub
    
    Private Sub Form_Click()
      Cls
      Print
      C1.RunTest
    End Sub
    Now compile natively (since RaiseEvent is sitting in the vbRuntime, native as well) -
    and the run the Executable and click the Form...

    This is, what I get here:


    Quite similar results for both versions (roughly 100ns = 0.1΅s) - so the overhead
    of RaiseEvent is roughly that of two nested function-calls - which is (being in the
    Sub-MicroSecond-range) not really that much to be concerned about (performance-wise).

    Olaf
    Last edited by Schmidt; Apr 17th, 2015 at 01:43 PM.

  17. #17

    Thread Starter
    Fanatic Member
    Join Date
    Nov 2014
    Posts
    553

    Re: Events – How They Work, CPU Intensive

    After reading your last post, especially the part where you were explaining how many connections there might be.


    And since COM supports "multiple SubScribers" (for each Event a COM-Server has to offer) - and because
    many COM-Servers expose more than one Event on their Interface(s), there's quite a lot of "connection-
    information" which has to be managed.

    Wouldn’t there have to be some type of a queuing mechanism in case a client is not able to keep up with the number of events fired?

    Wow what a twisted interconnected mess of interfaces, it has to be a management nightmare. Whether events backup, get queued or just dropped if not responded to quickly enough, I can’t image what happens during program termination or even worse a crash. With cleanup of pointers, references counters and objects, it’s amazing that Windows works at all.

  18. #18
    PowerPoster
    Join Date
    Jun 2013
    Posts
    4,930

    Re: Events – How They Work, CPU Intensive

    Quote Originally Posted by stuck-n-past View Post
    After reading your last post, especially the part where you were explaining how many connections there might be...

    Wouldn’t there have to be some type of a queuing mechanism in case a client is not able to keep up with the number of events fired?

    Wow what a twisted interconnected mess of interfaces, it has to be a management nightmare. Whether events backup, get queued or just dropped if not responded to quickly enough, I can’t image what happens during program termination or even worse a crash. With cleanup of pointers, references counters and objects, it’s amazing that Windows works at all.
    Short answer:

    With COM-Events there's no queuing-mechanism at all - it's just delegated function-calls we talk about here -
    (calls, which always "go through" to the EndPoint-Sink, if there is one - and that immediately).

    So, this is happening very deterministic (which is nice) - and in case of multiple SubScribers in exactly the order the
    SubScribers "came online" (registered themselves within the IConnectionPoints-List of the Event-Server-Instance).

    We have to differentiate between Windows-Messages (which in turn might raise COM-Events) -
    and the COM-Events-Raising-mechanism itself.

    Win-Messages might get queued (or removed from the queue, or re-ordered on the queue) -
    but this happens at a different level - as soon as a certain Message gets raised as a COM-Event,
    the thing will always behave as just explained (a normal, delegated Function-Call, fully going
    through, when SubScriber-Objects registered a Sink for the Event in question beforehand).

    So, in your own Apps (where you might use self-defined COM-Events - raising them from your
    own Procedures), you can rely on the fact, that from the code-point where you placed your RaiseEvent,
    the potential Receivers (if there are any) will *definitely* be called immediately - and there will be
    no "other code which places itself in-between", as long as you didn't place a DoEvents within a Sink.

    Olaf

  19. #19
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    5,685

    Re: Events – How They Work, CPU Intensive

    Quote Originally Posted by Schmidt View Post
    .....as long as you didn't place a DoEvents within a Sink.
    Oh this one gave me much headaches in the past!! Its a miracle I'm only slightly insane
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena


    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. -jmcilhinney

  20. #20

    Thread Starter
    Fanatic Member
    Join Date
    Nov 2014
    Posts
    553

    Re: Events – How They Work, CPU Intensive

    It’s like opening Pandora’s box! I get into a subject and before I know it I am being dragged deeper and deeper into the abyss with no end in sight. Learning the way events work or in my case don’t work, is quite amazing especially once you learn what all is involved.

    I was playing around with both VB and VC++ creating objects, connection points, attach and detach. I found that as long as I can get past the CreateObject function, everything else falls into place.

    I am also learning that one of the problems I am running into is the lack of consistency with Windows nomenclature. Even within the same document there’s like a dozen different names used in describing the same thing.

    So what’s happening, more often then not, I get errors when I am trying to use CreateObject as I try to get a reference to an ActiveX object

    Run-time error: ‘429’

    ActiveX component can’t create object.
    At this point I’m not sure what an ActiveX component is anymore? I built a simple DLL in VC++ which I used with CreateObject(DLL Name, Class Name) and that worked without a problem. I also successfully used "InternetExplorer.Application", and "MSComDlg.CommonDialog" in calls to CreateObject, worked like a charm.

    Thinking I was on a roll I tried a few others like, "MSComctlLib.StatusBar" or "MSComctl.StatusBar" and many others that all failed! Am I mixing apples and oranges here or am I totally headed down the wrong path once again? The code does not even have a chance to run, once it gets to the CreateObject call it throws error 429 at me and that’s all she wrote.

  21. #21
    PowerPoster
    Join Date
    Jun 2013
    Posts
    4,930

    Re: Events – How They Work, CPU Intensive

    Quote Originally Posted by stuck-n-past View Post
    At this point I’m not sure what an ActiveX component is anymore?
    ...
    Instantiation over the ProgID can be done in VB6 in two different ways:
    - CreateObject (usually used to create Instances which are not Control-COMponents)
    - Controls.Add (used to instantiate - and "site" - Controls by ProgID)

    So you have to differentiate a bit...

    In case you want to use that to create "Eventsinks on LateBound-Objects",
    the second mechanism above (Controls.Add) already offers such a LateBound
    and generic EventSink-Binding over the Type 'vbControlExtender'.

    Only for Non-Controls a few more efforts are needed, to achieve LateBound-
    Event-Sinking (e.g. Eduardo Morcillo has an example on his site - and the RC5
    has also a Class for it - cEventCollection).

    Not sure if that "LateBound-Events"-Topic is a correct guess on my end
    (with regards to what you plan to accomplish) - a working code-snippet
    would be nice from your end in any case.

    Olaf

  22. #22

    Thread Starter
    Fanatic Member
    Join Date
    Nov 2014
    Posts
    553

    Re: Events – How They Work, CPU Intensive

    Not a problem but it’s such a small piece of code I am not sure it will help. Again I am just trying to understand some of the differences between objects, ActiveX, COM, DLL, DCOM, OCX Ei - Ei - Oh


    Code:
        Dim Co As Object
    '
    '   Works
        Set Co = CreateObject("InternetExplorer.Application")
    '
    '   Works
        Set Co = CreateObject("MSComDlg.CommonDialog")
    '
    '   Error 429
        Set Co = CreateObject("MSComctl.StatusBar")
    '
    '   Error 429 - Was not sure if I had the proper name so I tried adding the 'Lib'
        Set Co = CreateObject("MSComctlLib.StatusBar")

    I don’t know for sure but it seems that OCX files are giving me the most problems. There are so many different flavors of Component Object Files it’s got me totally confused and lost.

    Is there anyway to check a COM's file header to determine exactly what it’s capabilities are before trying to use CreateObject?
    Last edited by stuck-n-past; Apr 25th, 2015 at 10:32 PM.

  23. #23
    Hyperactive Member
    Join Date
    Jul 2013
    Posts
    374

    Re: Events – How They Work, CPU Intensive

    Not sure if this is your case, but maybe worth a try:
    http://stackoverflow.com/questions/2...ndows-7-64-bit

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Click Here to Expand Forum to Full Width