I am having to use a 3rd party ActiveX DLL in my VB6 application. However, now that I've included the DLL in the references and used it in code, every time I quit my app, it also quits VB6.
I don't see anything in the logs or event viewer that would suggest why this is happening.
Is there anyway to prevent this?
Btw, I have contacted the vendor, but they are focused on their .NET products, it seems.
You may not be using the component correctly by missing specific initialization or termination calls, which has the affect of bringing down VBIDE. This usually happens when the third-party component or your application make Win32 calls.
I have had a few applications that I ran them through the debugger, they always terminated VBIDE. Yet, running the Release or Debug versions normally, resulted in the applications working just fine.
Try switching DEP off for VB6.exe only or altogether.
Also, this might be a license checking issue i.e. registry permissions -- try running VB6 IDE as Administrator (right click->Run as Admin)
I'm not a VB6 programmer by trade. I just mess around with the stuff. I have heard of this scenario referred to as sub-classing. Run a search on pscode.com. They have code and tutorial examples about how to prevent it. Good luck.
Ouch. I feel your pain.
Can you switch to a .Net component, and use it from VB6 via interop? I.e. write a COM-visible wrapper in VB.Net?
Just to close this question out... After spending significant time trying various things I ended up writing code that unloaded the control, paused for 5 seconds and then quit app. That seemed to do the trick.
Related
I was trying to automatically inject a dll to every process (including GUI) whenever it is started by a user . My DLL hooks DoDragDrop method of winapi and communicates with server to decide allow or disallow the drag & drop process. I use easyhook (particularly this tutorial) for hooking part. I created a gist for my code : Gist
In this url it says: Doesn’t work reliably against GUI applications. Stick to console apps. No wonder it didn't work in microsoft edge, and chrome.
I also tried code parts in these urls:
first
second
Finally , I already certificated my dll.
Is there any other way apart from appcertdlls? Thank you in advance.
Edit: I can't use appinitdlls, some users might have secure boot enabled.
Edit2: Seems like dlls in some tutorials is under system32 (this, and this) , and I moved mine under system32 too, but it did not
work.
PsSetLoadImageNotifyRoutine can be used, though it is a solution in kernel mode.
We are developing C++ apps (lots of MFC) with Visual Studio 2005 on Windows.
From time to time it happens that our nightly builds and/or unit tests hang because some part of some app or helper tool opens a message box in a corner case that is hit by the build.
Since the automated stuff is run (by a Windows Service) without any desktop session attached, obviously no-one can confirm - or even read - the GUI messages.
Is there any way to have Windows prevent apps from opening dialogs? Or maybe a tool that watches a service session that auto-kills any app that opens a dialog box?
I'm thinking that most cases where apps display unexpected popup-messages, it will end up calling one of the MessageBox* functions from user32.dll and it might be just possible to "magically" have these functions fail for a certain login-session? (Just a wild idea.)
Obviously the "right" fix is to have stuff not opening any dialogs, but with 3rd party tools it ain't always possible and with our tools it would be nicer to have a failing unit test that tells me the test "illegally" opened a message box than have a hanging unit test.
(Side notes: We're using Boost.Test for our unit tests and FinalBuilder for our automatic build scripts.)
Note: Removed original tags [continuous-integration build-automation automated-tests] and rephrased question to be more process centric.
You can load a DLL in each of the processes which puts a hook onto MessageBoxA and MessageBoxW. You can either do this manually or via the Detours library. You can then either have it return straight away without calling the real function or you could even implement some form of logging to notify your CI of the error.
We use AutoIt to automatically dismiss dialogs in our commercial run-as-windows-service application. The concept is described and some sample scripts are available here:
http://www.coretechnologies.com/products/AlwaysUp/AutoIt/
Note that some of the AutoIt functions don't work properly in Session 0 (e.g. WinActivate) but you can usually find alternatives. Be sure to test in Session 0!
We're starting a new custom project right now from a client and one of the requirements is the process cannot be terminated unless the system is shutting down, restarting, or logging-off.
This application monitors the USB interface. We will be using WMI to query the device periodically.
The client want's to run the application on Windows XP Operating System and doesn't like installing .NET. So we targeted Visual Basic 6 as our language.
My main concern is this application cannot be terminated. Our Project Adviser talks about Anti-virus and yes, some of the anti virus cannot be terminated. I was thinking how to do the same in Visual Basic 6. I know there will be API involved on the project but where should I go? so API is ok with me.
I saw some articles that converts the EXE to a SERVICE, create Windows Service in Visual Basic 6, etc.
So please .. share your thoughts.
If you want to be evil, you can call the (officially) undocumented RtlSetProcessIsCritical NTDLL function. This will immediately BSOD the machine if your process is terminated.
You cannot create a process that cannot be terminated without some sort of kernel-mode hooking, which involves writing a driver. You might want to look into Rootkits: subverting the Windows kernel if you're interested in that. However, even with kernel-mode hooking there are still numerous ways to terminate processes. The alternative is to use user-mode hooking, easily bypassed but enough for very simple projects.
The solution you want to use will depend on how far you want to go with the termination protection. And even if you do succeed in preventing process termination, there may be ways of preventing your application from working properly - e.g. killing the WMI service.
I think you want to look at writing an NT Service.
More info here: http://www.montgomerysoftware.com/CreatinganNTServiceinVisualBasic6/tabid/161/language/en-US/Default.aspxlink text
It's really frustrating coding in VB6 right now specially I dumped my head in C# for 2 years though I coded in VB6 for 5 years..
Moving back is a pain as if I am starting a new programming language.
To be honest, you are trying to do something in VB6 that it really isn't that great at.
When you say 'cannot be terminated' - what do you mean by that? There are several levels there:
a) App shows a window but the user cannot close it with the X button, or it does not show one
b) App shows no windows or maybe sits in task tray
c) App shows no windows and cannot be shut down from the Applications tab of task manager
d) App cannot be shut down from the process list of task manager
(a) and (b) are probably easiest to do in straight VB. (c) is still possible, but getting uglier. (d) gets you into hack territory and would almost certainly be frownd upon if you did manage it.
If you really need to stop users closing then you can probably hack it to a greater or lesser degree, but the real answer is as the others have said - a system service (this is exactly the srt of thing they were intended for). However that is one thing that VB6 isn't good at so the best solution to your problem is c#.
A co-worker of mine had downloaded a vb example project a while back to see how to make a call or two, he discovered it today again, and noticed that while sitting in the IDE the time/date is updating automatically when the entire project is not even running.
How does this work, we looked around for code but can't find anything giving it away.
Any ideas?
No enough info, really, but is it possible the time and date are part of a user control sited on the main form? In the IDE, user controls operate in a hybrid mode where their code can be running when the app itself is not.
I can't think of any other scenario where if the IDE is truly stopped, any code can be running.
The StatusBar control in Windows Common Controls can automatically display the current date and time. It updates its display even in design mode.
If you have ever developed controls yourself, you might have experienced an AHA! moment when you realised that your control code is running when the control is being used at design time in the IDE.
I have a little problem with visual basic 6 project. Everything works fine in the IDE
but the executable crashes every time, when I run the application. The application uses callbacks to communicate with a C++ dll. Even code as simple as showing a message box fails when the callback starts.
I changed the compilation mode to P-Code and still the problem persist.
Any help would be appreciate.
Thank you all
This sounds like the callbacks may be occurring on a different thread than your application is executing on. [EDIT: As I see Jim has already suggested.] If that's the case, yeah, kaboom just as soon as you "touch" anything OLE related or call into the runtime. Same story as with multimedia timer callbacks, fwiw, and I'd suspect you'll have to take the same precautions as one would with those if this is the case.
The short story with different thread callbacks is that you'll need to post a message to yourself, using PostMessage declared in a typelib so that the Err object isn't set by VB, then let the callback return. You do your own processing on receipt of the posted message. Here's the typelib I used for this with the CCRP Timers library:
http://vb.mvps.org/tools/files/postmessage.zip
Hope that helps...
Who's calling back to whom? Show us a little code.
The IDE can mask real problems, so just being able to run there is no guarantee that what you're doing is supported.
One common problem with callbacks is that VB6's runtime is not thread-safe, so if another thread is calling back into your VB code, you can't do anything that will invoke the runtime -- like access strings or objects.
There are ways around some of these issues, but I think we need to know more first.
Is the code being run from the same location as the IDE? Likely it is a reference problem, and you need to re-register the DLL.
A deployment package should make sure you have everything installed.
A few questions:
Is the executable on the same PC as it was developed, or a different one?
Does the file use a manifest file? If so, does mainfest call XP themes?
Also, if using manifest, does manifest use SXS for OCX files?