Hey guys, this question might be a little weird worded but I was looking to see if there was a way to add on to an executable. IE: I use the pandora one desktop application which works perfectly except it doesnt have global hotkeys. The hotkeys only work when the program is the active window. I was thinking of making something that would trick the client into thinking it was the active window when it wasn't so I could use the hotkeys globally.
This question could be generalized to any program (.executable) out there for windows. Is there a way to add on to a "finished" program?
Thanks!
What you could do is write an application that registers global hotkeys, then SendMessages the other application.
Here is a C# example:
Send key strokes to another application C#
or
http://www.codeproject.com/KB/cs/SendKeys.aspx
Related
I am not sure how to ask the question so here is a picture of some idea that came to mind
So for example, when you run my "custom launcher" it displays a window with a couple buttons on the side which you can assign values to. When you click on a button, the appropriate program will run in the big panel on the right (in window mode).
This is all from the user's perspective of course. They will just see that the program they want to run appears in that panel. The actual implementation may have nothing to do with "one program running inside another program"
My own use case is limited to windows desktop platforms only, but if it is possible to generalize it that would be nice as well.
Is this actually possible? Can I write such a program that will run another program inside a panel? The program that's launched may be someone else's, such as MS paint or calculator.
Just to expand on my comment above, here is an approach that may work for you: Fake it :)
When you launch the program, intercept all windows messages to the program that control it's position on screen. That way it 'appears' to be fixed in place, but in reality it's still attached to the normal Windows desktop.
Here's some light reading for you:
Windows Event Hooks
A hook is a mechanism by which an application can intercept events,
such as messages, mouse actions, and keystrokes. A function that
intercepts a particular type of event is known as a hook procedure. A
hook procedure can act on each event it receives, and then modify or
discard the event.
I would recommend against it in a commercial application because you are modifying the behavior of software you don't own - that software may make assumptions about what its parent window is, but for experimentation there's the SetParent Win32 function.
Hey guys, I've finished my little calculator and now what I want to do is this:
I want to be able to run it in the background until I press, say, Control + C and then have it open...is this possible in OS X? I recall it being pretty simple in Windows...where should I begin to look?
I feel like it will involve running as a service or something...
One solution is to have your calculator provide a Service. A Service can be assigned a global key combination. When the combination is pressed, your calculator application can open, and ideally, perform a task on the user's current selection.
To assign a service a specific key combination see:
System Preferences > Keyboard > Keyboard Shortcuts
An alternative approach is to create a background application. This application can register for a global hot key combination. When the combination is pressed, the background application can launch your calculator.
Maybe a setting up a global hotkey.
I found and use the example here. Which works really well.
There where mixed thoughts on if apple would fully deprecate the Legacy API used,And I think
there is a new API. But for the life of me can not find it again.!
Ah! found it it was in the NSEvent Class Reference : * addGlobalMonitorForEventsMatchingMask*
I want to respond to a certain type of new window being opened by an external application. I have some experience finding applications and windows currently open (system wide) using some of the carbon functionality, so could theoretically just check every few seconds. This would require getting a list of all open windows and checking it against some list I would have to maintain, and feels very clunky.
How can I get a simple, clean notification when a new window is launched? Should I use the accessibility API? If so, what specifically am I looking for?
First, create an AXObserver. Then, watch for launches of any applications that you think you'd be interested in. When such a launch occurs, create an application AXUIElement for that process, and add your observer to it for the kAXWindowCreatedNotification notification.
I question whether this is the best way to do whatever you're trying to do. You might step back a bit from this solution (that is, watching for new windows) and ask another question about your goal.
I don't really know where to begin. Let's start with the stupid questions:
What language should I use for this? What is suited for the task at hand?
Next, the real ones:
Is there a way to stop the screensaver from starting, short of changing the cursor position? If not, will changing the cursor position even work?
SetThreadExecutionState will prevent the screensaver from coming on or the machine from automatically going to sleep if you pass the ES_CONTINUOUS and ES_DISPLAY_REQUIRED flags.
I wrote an app awhile ago that does exactly what you are asking for. It runs as an icon in the System Tray, not the Taskbar, and uses a global message hook to disable the WM_SYSCOMMAND/SC_SCREENSAVE notification from reaching any applications. If that notification does not reach the DefWindowProc() function, the screen saver will never run.
Your program does not need to be visible in the task bar at all.
You don't even need a program at all, if you can disable the screensaver in the registry.
What you want to do can perhaps be achieved by sending a MOUSE_MOVE event to the desktop window. If you want to use C# (the only language I am current with right now), you can look at this article, but maybe a simple C program using the WinAPI is better suited for this task.
.NET will easily allow you to put an application in the system tray (checkout the NotifyIcon object in System.Windows.Forms.Controls).
I believe you can use the SetCursorPos (http://msdn.microsoft.com/en-us/library/ms648394(VS.85).aspx) API call to prevent the screen saver, just make sure you set them to the current location so you don't actually move the mouse.
Using the Apple OS X Cocoa framework, how can I post a sheet (slide-down modal dialog) on the window of another process?
Edit: Clarified a bit:
My application is a Finder extension to do Subversion version control (http://scplugin.tigris.org/). Part of my application is a plug-in (a Contextual Menu Item for Finder); the bulk of my application, however, is in a separate daemon proces. For several reasons, we've chosen to put virtually all the code into the daemon; the plug-in only defines the menu itself, and Apple-Events over to the Daemon.
Sometimes, the daemon needs to prompt the user for further information. It can toss a window on-screen for this, but that's disruptive (randomly positioned), and it seems to me the work flow here is legitimately modal, for example "select a file, pick 'commit' from the menu, provide commit comments, do the operation."
Interprocess cooperation (such as passing a reference of some kind) is acceptable: both processes are mine, but I want to avoid binding the sheet's code into the primary process.
Really, it sounds like you're trying to have your inter-process communication happen at the view level, which isn't really how Cocoa generally works. Things will be much easier if you separate your layers a bit more than that.
Why don't you want to put the sheet code into the other process? It's view code, and view code is inherently process-specific. The right thing to do here is probably to add somewhat generic modal-sheet support to your plugin code, and an IPC call that your daemon can make to summon that code. Trying to ship view objects over to the remote process is going to be nightmarish if you can make it work at all.
You're fighting the frameworks with this approach.
You can't add a sheet to a window in another process, because you have at most only the most restricted access to the windows in the other process.
Please don't do this. Make the interaction nonmodal if at all possible. Especially in something like a commit, it's much nicer to be able to browse around your files while you're writing commit comments.
OS X does have window groups, but I don't think they can (easily) span applications.
Another thing to consider is that in OS X it's possible to have many Finder windows open on the same folder (unlike in OS 9). Even if you did have sufficient privileges/APIs to add a sheet to a Finder window, it's not like the modality of that window would prevent the user from being able to continue working with the files.
(My personal opinion as a long-time Mac user is that this kind of interaction would drive me right up the wall.)