I wrote this simple AHK script, it's working. But rightclick systray icon- suspend/pause, it just still keep working. Is it because of something in my code? or about win7 x64?
#Persistent
return
OnClipboardChange:
WinGetActiveTitle, OutputVar
IfWinExist, collect.doc
{
WinActivate ; use the window found above
send,^v
send,{Enter}
winactivate,%Outputvar%
}
else
tooltip,need collect doc,400,400
Sleep 100
return
Both Pause and Suspend are not meant to block automatically called subroutines like OnClipboardChange or GuiClose. Pause merely blocks the current thread, which means that every newly created thread will still run, and a clipboard change does create a new thread. Ergo, Pause can't block it.
In such cases, you need to implement an own piece of logic within the "event subroutine" that checks some kind of state.
Going with your premise to make the functionality depend on the paused state, a fairly easy way would be to check for the built-in A_IsPaused:
OnClipboardChange:
if(A_IsPaused) {
return
}
msgbox, 'sup?
return
There are certainly many ways to implement this. You could also define your own hotkey to activate/deactivate/toggle a custom state.
P.S:
Activating a window only to paste some text seems a bit unnecessary and bothersome to me; have a look at the Control commands (e.g. Control, EditPaste) or access Word via COM. Depending on what you do, I believe directly writing to a text file and/or in-memory storage might be a better alternative to a running Word instance anyway.
P.P.S:
You might want to be careful with such a negligent clipboard logger. I assume you don't want every kind of data (e.g. passwords) showing up there.
Related
I am trying to cancel when a process calls wait(), read(), recvfrom() or similar, because if I use ptrace on it, after the PTRACE_ATTACH and later PTRACE_CONT, my tracer becomes blocked until the function in the tracee returns. Also I think it happens the same with sleep().
Would be possible to cancel the call, or reproduce a fake return?
Thanks.
Yes, you should send a PTRACE_INTERRUPT. This will trigger the syscall to exit.
To do this, you need not to waitpid on your tracee, because that would block you (the tracer) too.
You can either have multiple threads: one that will block on the tracee, one that will "decide" to cancel the blocking syscall - e.g. a GUI thread that the user will press "cancel" (like a normal debugger, e.g. GDB).
Or you can use PTRACE_SYSCALL to manually diagnose every syscall the program is doing and then decide preemptively if you wish to execute that syscall. This way you can decide to not run wait at all, or perhaps mock them by having your return value instead.
Can anyone tell me offhand if SVN::Hooks::Notify's NOTIFY and NOTIFY_DEFAULTS blocks replace (or rather, stop the evaluation of) the POST_COMMIT block? My PRE_COMMIT block works fine, and my existing NOTIFY/NOTIFY_DEFAULTS blocks process just fine.
However, nothing I have under the POST_COMMIT block fires at all... and yes, hooks/post-commit is linked to the script. The perdocs for svn::hooks::notify state that it runs within POST_COMMIT, but I would prefer to do some extra processing first before kicking off a notification email (eg, inserting pertinent information into a db table for later use).
The NOTIFY block sets a post-commit hook; there is no separate hook for notify.
And as far as I can tell from the SVN::Hook source, you can have set as many of a given hook as you want, and they will run in the order you add them in. So you may need to do e.g.:
use SVN::Hooks;
BEGIN {
POST_COMMIT { ... }
}
use SVN::Hooks::Notify;
to have your other hook come before the notify hook.
I am currently working on a matlab gui and after some beginner's problems with the data handling I am quite satisfied with the result.
There is just one hiccup: whenever the program is done running, the gui becomes unresponsive and the buttons and text elements vanish, all I can see is the background.
I have scanned the functions thoroughly for close all; statements and such, but there is nothing there.
How do I return 'clean' to the gui so I can put in more data? Do I need to put the gui in a constant while loop?
best wishes
Chris
You can do the following:
Modify the attribute of your controls to be interruptible:
set(handles.figure, 'Interruptible','on');
Create a callback function based on pressing a determined key combination.
set(KeyPressFcn, #resume_fcn);
Create a callback function that solves the problem.
function resume_fcn()
if eventdata.Key = ...
exit;
end
end
However, the consistency of data may be lost. In case you don't want to return 'clean' to the gui, you can type:
delete(get(0,'Children'))
I am creating function (for example) to validate content, then if it is valid, close the view, if it is not, present further instructions to the user. (Or other such actions.) When I go to name it, I find myself wondering, should I call it -doneButtonPressed or -validateViewRepairAndClose? Would it be better to name the method after what UI action calls it, or name it after what it does? Sometimes it seems simple, things like -save are pretty clear cut, other times, and I can't thing of a specific example right off, but I know some have seemed like naming them after what they do is just so long and confusing it seems better to just call them xButtonPressed where x is the word on the button.
It's a huge problem!!! I have lost sleep over this.
Purely FWIW ... my vote is for "theSaveButton" "theButtonAtTheTopRight" "userClickedTheLaunchButton" "doubleClickedOnTheRedBox" and so on.
Generally we name all those routines that way. However .. often I just have them go straight to another routine "launchTheRocket" "saveAFile" and so on.
Has this proved useful? It has because often you want to launch the rocket yourself ... in that case call the launchTheRocket routine, versus the user pressing the button that then launches the rocket. If you want to launch the rocket yourself, and you call userClickedTheLaunchButton, it does not feel right and looks more confusing in the code. (Are you trying to specifically simulate a press on the screen, or?) Debugging and so on is much easier when they are separate, so you know who called what.
It has proved slightly useful for example in gathering statistics. The user has requested a rocket launch 198 times, and overall we've launched the rocket 273 times.
Furthermore -- this may be the clincher -- say from another part of your code you are launching the rocket, using the launch-the-rocket message. It makes it much clearer that you are actually doing that rather than something to do with the button. Conversely the userClickedTheLaunchButton concept could change over time, it might normally launch the rocket but sometimes it might just bring up a message, or who knows what.
Indeed, clicking the button may also trigger ancillary stuff (perhaps an animation or the like) and that's the perfect place to do that, inside 'clickedTheButton', as well as then calling the gutsy function 'launchTheRocket'.
So I actually advocate the third even more ridiculously complicated solution of having separate "userDidThis" functions, and then having separate "startANewGame" functions. Even if that means normally the former does almost nothing, just calling the latter!
BTW another naming option would be combining the two... "topButtonLaunchesRockets" "glowingCubeConnectsSocialWeb" etc.
Finally! Don't forget you might typically set them up as an action, which changes everything stylistically.
[theYellowButton addTarget:.. action:#selector(launchRockets) ..];
[theGreenButton addTarget:.. action:#selector(cleanUpSequence) ..];
[thatAnimatingButtonSallyBuiltForUs addTarget:.. action:#selector(resetAll) ..];
[redGlowingArea addTarget:.. action:#selector(tryGetRatingOnAppStore) ..];
perhaps that's the best way, documentarily wise! This is one of the best questions ever asked on SO, thanks!
I would also go with something along the lines of xButtonPressed: or handleXTap: and then call another method from within the handler.
- (IBAction)handleDoneTap:(id)sender {
[self closeView];
}
- (void)closeView {
if ([self validate]) {
// save and close
}
else {
// display error information
}
}
I run into this regularly, and am just looking for best practice/approach. I have a database / datamodule-containing app, and want to fire up the database/datasets on startup w/o having "active at runtime" set to true at design time (database location varies). Also run a web "check for updates" routine when the app starts up.
Given TForm event sequences, and results from various trial and error, I'm currently using this approach:
I use a "Globals" record set up in the main form to store all global vars, have one element of that called Globals.AppInitialized (boolean), and set it to False in the Initialization section of the main form.
At the main form's OnShow event (all forms are created by then), I test Globals.AppInitialized; if it's false, I run my "Initialization" stuff, and then finish by setting Globals.AppInitialized := True.
This seems to work pretty well, but is it the best approach? Looking for insight from others' experience, ideas and opinions. TIA..
I generally always turn off auto creation of all forms EXCEPT for the main form and possibly the primary datamodule.
One trick that I learned you can do, is add your datamodule to your project, allow it to auto-create and create BEFORE your main form. Then, when your main form is created, the onCreate for the datamodule will have already been run.
If your application has some code to say, set the focus of a control (something you can't do on creation, since its "not visible yet") then create a user message and post it to the form in your oncreate. The message SHOULD (no guarantee) be processed as soon as the forms message loop is processed. For example:
const
wm_AppStarted = wm_User + 101;
type
Form1 = class(tForm)
:
procedure wmAppStarted(var Msg:tMessage); message wm_AppStarted;
end;
// in your oncreate event add the following, which should result in your wmAppStarted event firing.
PostMessage(handle,wm_AppStarted,0,0);
I can't think of a single time that this message was never processed, but the nature of the call is that it is added to the message queue, and if the queue is full then it is "dropped". Just be aware that edge case exists.
You may want to directly interfere with the project source (.dpr file) after the form creation calls and before the Application.Run. (Or even earlier in case.)
This is how I usually handle such initialization stuff:
...
Application.CreateForm(TMainForm, MainForm);
...
MainForm.ApplicationLoaded; // loads options, etc..
Application.Run;
...
I don't know if this is helpful, but some of my applications don't have any form auto created, i.e. they have no mainform in the IDE.
The first form created with the Application object as its owner will automatically become the mainform. Thus I only autocreate one datamodule as a loader and let this one decide which datamodules to create when and which forms to create in what order. This datamodule has a StartUp and ShutDown method, which are called as "brackets" around Application.Run in the dpr. The ShutDown method gives a little more control over the shutdown process.
This can be useful when you have designed different "mainforms" for different use cases of your application or you can use some configuration files to select different mainforms.
There actually isn't such a concept as a "global variable" in Delphi. All variables are scoped to the unit they are in and other units that use that unit.
Just make the AppInitialized and Initialization stuff as part of your data module. Basically have one class (or datamodule) to rule all your non-UI stuff (kind of like the One-Ring, except not all evil and such.)
Alternatively you can:
Call it from your splash screen.
Do it during log in
Run the "check for update" in a background thread - don't force them to update right now. Do it kind of like Firefox does.
I'm not sure I understand why you need the global variables? Nowadays I write ALL my Delphi apps without a single global variable. Even when I did use them, I never had more than a couple per application.
So maybe you need to first think why you actually need them.
I use a primary Data Module to check if the DB connection is OK and if it doesn't, show a custom component form to setup the db connection and then loads the main form:
Application.CreateForm(TDmMain, DmMain);
if DmMain.isDBConnected then
begin
Application.CreateForm(TDmVisualUtils, DmVisualUtils);
Application.CreateForm(TfrmMain, frmMain);
end;
Application.Run;
One trick I use is to place a TTimer on the main form, set the time to something like 300ms, and perform any initialization (db login, network file copies, etc). Starting the application brings up the main form immediately and allows any initialization 'stuff' to happen. Users don't startup multiple instances thinking "Oh..I didn't dbl-click...I'll do it again.."