Welcome to Hardcode Sign in | Join | Help

December 2005 - Posts

However if you show the form in modeless it appears fine. I found a workaround (put it in Form_Activate):

    Declare Function ShowWindow Lib "user32" (ByVal hwnd As Long, ByVal nCmdShow As Long) As Long

    ShowWindow Me.hwnd, vbHide
    Me.Caption = Me.Caption
    ShowWindow Me.hwnd, vbNormalFocus

Ok so what if a COM method is invoked when the ActiveX server is displaying a modal dialog ? It processes using the message loop of it. However - what if this method call needs to tell the server to quit ? I've fixed the problem by adding a reference count and incrementing / decrementing it near each MsgBox. Afterwards I got the "Quit" call to be executed asynchronously using a timer that would fire when the nModalDialogs reference count gets to zero.
This message appeared today when instantiating our ActiveX components under a limited user account. Now - I've discovered the default security settings forbid instantiating of COM objects under non-admin accounts. To change the default permissions, open OLE View then File / System configuration / Default launch permissions and add Everyone (if still not working add the actual limited users). The same should be done on "Default access permissions".
You should be able now to instantiate COM components under a limited account - if still not verify the NTFS file permissions to the actual dll / ocx files.
I've been very busy these days with university homeworks (unfortunately written in Jess and GPSS - expert systems etc) - will be back soon with interesting stuff.
Meanwhile - the last problem I had to solve was designing a synchronization system over a database table i.e. many clients editing it and synchronizing its data in real-time. Currently the best solution I've been thinking at is using a "last modification" timestamp for each record and polling a query from a timer. Now - this obviously doesn't catch the deletes so I must also prepare another table where a delete trigger writes the deletion timestamp.
While I never worried about the OpenGL stack limits - for the first time I ran into them (the modelview stack specifically). Now - I don't believe this is stored on the video card so the driver should have set it unlimited ( if not, definitely a larger limit than 32). There was no problem with the engine design - when you have the scene as a tree and render it recursively you have to use the matrix stack.
Anyway - I've ended up wrapping the glPushMatrix / glPopMatrix to use a local defined matrix stack instead of the OpenGL one.

Managing the focus when you have a C++ ActiveX hosted in a VB client is already a pain in the *ss, however what you're doing when you have a Visual Basic control hosted again in the Visual C++ component ? Nothing worse than that - think again: they are composites i.e. the C++ component has a child window and the hosted VB component also has child windows - and all focusable (editboxes mainly).

The only workaround I found for getting OnKillFocus fired on the childmost controls was to check somewhere on a timed event if the GetFocus window is different from a initially set one – really a desperate resolution.

Well, some people are MVPs in C#, some in SQL Server, and so on - high-tech stuff. And I've just found this guy that is MVP for MS Paint :D.

Yes, they are coming to Bucharest for a concert next year on 23 June. Tickets are on sale starting January 1st, 2006. Comments by Pisi and Dragos also.