I mean preventing any action closing-unloading-terminating they all should be prevented until the code finishes working..
Esspecially termination should be canceled until code finishes working..
I want to do this to create a very important .log file and with it moving some files between folders so i must prevent the guy that thouches everything in server without knowing a thing about and being called as system administrator from stopping this action just cause he doesnt like it to run in the background (if u got what i mean). Cause im having log about that server and moving files which can cause data loss. Im pretty sure most of the programmers lives trough such unnecessary thrust problems with old people and i need help to deal with this situation.
So how can i achive that in vb6?
You probably need to redesign your application logic to allow terminating your process at any stage - move files by rename_src-copy-rename_tgt-delete_src operations, close log file after each event written etc etc. Ideally you should be able always identify which operations are done purely on info, provided by file system (file names etc).
There are cases when terminating process is required, after all.
Otherwise, if your application has visible window, you can track Form_QueryUnload events and just cancel unload. Of course this doesn't prevent killing your app from task manager processes view.
While you can stop the user from trying to close the application by handling the QueryUnload event (assuming you call DoEvents periodically) there is nothing you can do to stop someone with full admin rights killing your process outright.
Related
I am seeking a possibility to always trigger a second application whenever another application gets started (ideally: right before the latter gets started but probably more or less "at the same time" will suffice).
The issue at hand is, that our company's IT folks for some to me unexplicable reason insist on constantly "adjusting" some Windows registry entries. One of those entries is the flag to memorize the passwords for the mail servers that Outlook keeps polling. Having to re-enter these passwords over and over again is driving me nuts and so meanwhile I also figured out which entries I have to revert to stop this nonsense. I thus now have a .reg file that I always "apply" to the registry right before starting Outlook and that helps me to maintain mental health.
But it is of course tedious to always have to click TWO icons in sequence, when opening my mail app. (Outlook). So, while I could certainly replace all Outlook "shortcuts" with shortcuts to a script file first applying the registry patch and only then starting Outlook I was wondering whether there wouldn't be a more elegant solution.
My question thus: is there an option or tool (e.g. in Windows' task-scheduler) to trigger the start of an application 'B' whenever a specific application 'A' gets is (or is about to be) started?
How do you call the feature of OSX being able to restart, but persisting each process state, in a way that after restating is finished it can restore each one of these processes exactly how they where previously?
For example a movie would still be paying in the same part, a text document would still have half of the sentence written even if I didn't save the txt file to disk, the browser would still have the same tabs opened and the same amount of scroll done, etc.
People call it in many different ways but "Application persistence" and "State Restoration" seem to be the most "official" ones.
I very rarely close down Visual Studio intentionally. The project I'm working on is so ginormous that it takes about 15 minutes just to load it up, so it's been my practice just to leave the solution open overnight so that it'll be ready for me the next morning. The only time I have to restart the program now is if it crashes - which - happens. Every once in a while I'll do something it doesn't like and it quits on me. I accept this. I'd love for it to be bullet-proof, but I hardly expect that.
The downside of this is that apparently, any settings you change in the program while it's running (fonts and colors, keyboard shortcuts, auto-formatting settings, basically anything in the Tools/Options dialogue) are only saved when you quit the program legitimately. These settings are not saved when it crashes. So I find myself having to redo any settings changes I made every single time.
First off - why the heck doesn't it save the settings when you change the settings? How hard would that be? It's a certain level of hubris to take it on faith that your program will always close normally and not bother saving state until the shutdown process. (And not having it save settings in an abnormal shutdown process either) I'd get fired (or at least reprimanded) for writing code that did that, so how does Microsoft get away with it? And is there some way of forcing it to save settings without quitting and reloading?
As far as I know, the only thing you can do in your situation is to export your settings directly after you change them, and import them after a crash. This way your settings are safe, and you don't need to restart.
The Qt documentation for QWidget::activateWindow() states:
On Windows, if you are calling this
when the application is not currently
the active one then it will not make
it the active window. It will change
the color of the taskbar entry to
indicate that the window has changed
in some way. This is because Microsoft
does not allow an application to
interrupt what the user is currently
doing in another application.
However, Skype appears to defy this rule. If Skype is running but is not the active application, I can launch it from the start menu and it brings the existing instance to the foreground, activates it and grabs input focus.
And how can I do this?
(NOTE: This is specific to how QtSingleApplication works)
The solution is stupidly simple for my issue. Simply call AllowSetForegroundWindow(ASF_ANY); at the beginning of the application, and the original process will thus be allowed to bring itself to the foreground by use of SetForegroundWindow(). No strange hacks, just one line of code to add and no need to modify QtSingleApplication either.
I don't think you can do it reliably with the Qt API alone.
There are multiple solutions for windows. E.g. here, and here, and here.
The method I've used before is to declare a shared memory section, and write the application's window handle there. Later, when a second instance of your program is started, you can find the window handle of the first and activate it.
I don't think you have the issue of windows preventing you from doing this in this case, because your second instance is the active application, so it is allowed to 'pass focus' to other windows.
Use Single Application in Qt Solutions
For some applications it is useful or
even critical that they are started
only once by any user. Future attempts
to start the application should
activate any already running instance,
and possibly perform requested
actions, e.g. loading a file, in that
instance.
you can set the setWindowOpacity from 0 to 1 .the only thing is you may open it all the time
This is a very general question:
I was wondering whether it is possible to find out whether an application (any kind of application no matter if it a delphi-application or java or whatever) was started by a user or by another application? And if it is possible and I see that an application was called by another one, can I find out what the "father" application is, that called the new programm?
Thnx in advance!
EDIT: Maybe it is too general - How can I see whether a Delphi application has a parent application with Delphi itself, e.g. one application was started by a service and I need to find that service?
Every single running application has a parent application, which launched it (except for root system process).
It is not possible to tell, whenever it is user who directly clicked on application to lauch it or not.
Example: take Explorer shell (not Internet Explorer).
You can double click on any application to launch it. The parent process will be explorer.exe.
You can right-click on any file and a bunch of context menu extenders will load. Some of them may launch external applications to, say, create a preview of video-file (I saw this, swear!). The parent process will be explorer.exe, but user didn't indended to lauch any application. He just wants to view file's properties. He didn't even know, that applications were lauched!
Example: take Total Commander or any other two-panel file managers, which supports plugins for archives.
You can double click on any
application to launch it. The parent
process will be totalcmd.exe.
You may enter archive file and copy
(extract) few files from it to your
Documents folders. Corresponding
plugin may handle extraction by
itself or run invisible process to
handle all work. All you see is
progress bar in Total Commander. But
there is a new proces and its parent
is totalcmd.exe again.
There are no differences between cases 1 and 2 in both examples.
BTW, the definition "started by user" is unclear. You even may say that nothing can happen without user's command. All those background processes in cases #2 were launched because user asked for it. Well, user didn't asked for lauch explicitly, but he asked for operation itself.
You don't mention if you want to do this programmatically or if you're looking for a tool to just show the information.
If you just want to view the information, you can use Process Monitor, part of SysInternals:
http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
In the Tools menu, there is a 'Process Tree' view that shows you a tree with parent / child process relationships and as well as the owner of each process.
If you want even more detail about processes, look at Process Explorer:
http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx
if it started by the user from windows so the parent will be explorer.exe, otherwise the parent will be the application which run the process.
to check the parent of a process by using tool check Ander Miller reply.
Did you see this question?
I'm not sure that I see problem right now.