Taking notes to a background text editor without switching windows - windows

I am looking for a solution to a specific use case:
When I read something on my browser or pdf reader, I want to take notes without switching windows. I want to type right on my browser or pdf reader, but the typed text should go to the background text editor like notepad.
Is this possible?
Do you know any existing automation script that handles this use case?

You should create an application that uses some keylogger-like techniques (e.g. global hooks) to monitor the keypresses and, depending on some condition (a setting you may have set, the currenctly active window, ...), it may pass them normally to the application or suppress them to store them in a buffer. Such buffer, then, would be shown to the user as needed.
Still, in my opinion a much more convenient way to perform a similar task would be to create an application consisting of a semitransparent edit box, that could be shown and hide simply with a hotkey. This would avoid all the hooks stuff and the potential problems that may arise from them.

you might try using autohotkey scripting language... I can write a little script that would do exactly what you need and afaik in this particular case it wouldnt need keyboard hooks.
--EDIT--
Autohotkey is VERY simple to use/learn so even if you want to do the script yourself you can do it in a very short time even if you dont have any knowledge of ahk. Then again, I can help you with it.

Related

Handle GUI window changes

I'm doing an automation script for installation wizards using AutoIt. I'm trying to handle window changes in some way.
Can some one explain how these GUI's work?
When I click on the Next button it looks just like the components in the GUI is beeing changed. Is this tha case? Or is a new window created and the old destroyed?
I've noticed that the process ID is the same for all windows.
I'm sure there is some way to know which "state" the GUI is in, or which step?
By the way. All the windows has the same title.
Thanks
/Anders
This will be dependant on the program you are automating.
The easiest approach would be to look at what changes in the GUI between stages, likely candidates are if there is a label that is giving instructions for that step, or a button that has text changing (e.g. if the button says "Finish" then you know your at the end).
Most installer programs have child windows for grouping the controls of each stage. These are typically implemented as dialog resources (as can be seen when using something like reshacker on them). So although the window remains the same, the panels are being created/destroyed as appropriate. This is a very neat method of doing it, for the obvious reason that you don't need to have to code to create/destroy a lot of controls. Resource created dialogs don't have nice class names like windows sometimes do though, so this may not be a reliable way to check the state.

Is there a way to parent a standard Windows dialog inside another form?

I know it's possible to take a dialog that you built yourself and parent it on another form. But is it possible to parent a standard Windows system dialog on a form that you designed?
Specifically, I'm trying to set up a form with multiple tabs that provide different ways to obtain a reference to data used by the program. One of those tabs should represent the file system, and the ideal way to do this would be with the standard Open dialog that can be instantiated with the COM identifier CLSID_FileOpenDialog.
Is there any way to take a system dialog and cause it to appear parented on another window, without the border, title bar, etc?
There are ways to use a hook, either via SetWindowsHookEx() or SetWinEventHook(), to grab a system dialog's HWND, then you can do whatever you want with it, such as call SetParent(). But just because you CAN does not mean you SHOULD. System dialogs are designed to run as their own windows, not embedded in someone else's window. A better solution might be to use the same Shell display components that are used by Windows Explorer (and system dialogs) via IShellFolder::CreateViewObject() or SHCreateShellFolderView(), or find a third-party solution that does the hard work of interacting with the Shell for you.

General Question about a GUI to execute a batch file

I'm new to programming and have taken some classes in it so I'm not sure if this is possible. I want to use a COTS software called 010 Hex Editor and write a script for the program to automate a couple tasks. These tasks can be run from a batch file according to their documentation.
Then I want to instruct the user to eject the device and reinsert it to clear the cache. (This I want done just with a simple pop-up window.
Then I also want to format the device which I assume can be done in a batch file as it can be done through dos on Windows.
My question is, with these 3 steps, can I build a simple GUI that has a button that says, "Start" or something like that, then the pop up window comes up to eject and reinsert, and then another button to format, and another button to exit. I'm not really familiar with what language this could be done in, and how to do this as the C++/Java classes I've taken have been more about syntax and OOP. Thanks!
You can use the windows messenger service to put up an alert - but on newer windows (vista/7) it's a pain to set all the permissions to allow this.
There are lots of free utilities that will popup a dialog from the command line, with a given message and wait for a response.
They are generally called messagebox or msgbox - sorry can't recommend any in particular

Creating quick GUI front ends

I wanted to have a GUI front-end for a script that accepts numerous command-line options, most of them are UNIX paths. So I thought rather than typing them in (even with auto-completion) every time, I'd create a GUI front end which contains text boxes with buttons beside them, which when clicked will invoke the file browser dialogue. Later, I thought I'd extend this to other scripts which would sure require a different set of GUI elements. This made me think if there's any existing app that would let me create a GUI dialog, after parsing some kind of description of the items that I want that window should contain.
I know of programs like Zenity, but I think it's doesn't give me what I want. For example, if I were to use it for the first script, it'll end up flashing sequence of windows in succession rather than getting everything done from a single window.
So, basically I'm looking at some corss-platform program that lets me create a window from a text description, probably XML or the like. Please suggest.
Thanks
Jeenu
Mozilla's XUL is a cross platform application framework - . You could write an app as a Firefox plugin or a standalone XUL application.
mono and monodevelop could work for this. Or even something super simple like shoes.

Can an app use the clipboard for its own purposes? (read: who owns the clipboard?)

In PowerBuilder's IDE, the code autocomplete feature uses the clipboard to communicate the completed text to the code window. By doing so, it overrides whatever was stored on the clipboard before. So, if you had the winning numbers of the next lottary stored on your clipboard, and you used the autocomplete to turn m_goodfor into m_goodfornothing, you've just lost your only chance of ever getting rich, and you're left with nothing on your clipboard.
Features like that are the reason I hate software. It looks like it was implemented by some intern that noone was looking after. However, there's also a chance I got all worked up for nothing, and making such use of the clipboard is absolutely legit. So, can an app use the clipboard for its own purposes? Who is considered the owner of the clipboard?
(Bonus votes to whoever puts himself in place of the feature's programmer, and provides some reasoning for this being done on purpose, assuming the users would actually benefite from it)
You are probably right on the intern reasoning. There is absolutely no reason why an application would use the clipboard to communicate information other than pure laziness. Even between processes, there are other, better ways of communicating information.
Other then letting the user paste information in another application, there is no reason to use the clipboard.
The programmer did it because it was easy, and put his needs above those of the end user. There are many programs that do this, particularly add-ins to outlook, VB, etc., which copy/paste their buttons onto the toolbar. Any user that runs a clipboard extender (like my own ClipMate) will absolutely hate this behavior (and you'll be "busted" right away).
Here is my favorite quote on the subject:
“Programs should not transfer data into our out of the clipboard without an explicit instruction from the user.”
— Charles Petzold, Programming Windows 3.1, Microsoft Press, 1992
An app should never change anything on the clipboard without the user initiating that action. My .02 anyway.
Bonus votes to whoever puts himself in place of the feature's programmer, and provides some reasoning for this being done on purpose
Using clipboard for application communication
They are always a better way to do it. The programmer might have done it this way because it was faster to implement OR because he really wanted to have this value in the clipboard after the action. At least, if he didn't wanted to have it in the clipboard he could have get the value from the clipboard, store its value then replace the old content of the clipboard inside the clipboard and everything would have be more "transparent" ans less frustrating for the end-user.
I have built a piece of functionality into an App that uses the clipboard. Business was requesting a way for users to seamlessly capture a screen shot and upload it.
I worked with the business to develop it and what we came up with was a user simply hit the print screen key and clicked "upload" in my app.
The Java Applet running in the background pulled the image off the clipboard and displayed a formatted preview to the user, The user then added in a file name and description and clicked save.
Using the clipboard this way saved the user the time of having to capture the screen shot save it somewhere then find it through an upload interface. Even if we did go that route by the user hitting print screen to capture the image in the first place they are already overwriting whatever was on the clipboard in the first place.
Using the clipboard isn't all bad but I certainly agree using it in an IDE is a def no no.

Resources