Messages - tranglos [ switch to compact view ]

Pages: prev1 2 3 [4] 5 6 7 8 9 ... 213next
N.A.N.Y. 2012 / Re: NANY 2012 Release: Ethervane Echo
« on: July 09, 2012, 12:26 PM »
People are using the VB6 IDE in Win 7 64 bit.
VB6 only comes in a 32 bit version.

I don't use VB, sorry :-)

Delphi now has a 64-bit version, and I could upgrade to it, but in order to continue development I'd also have to upgrade several third-party libraries. That last thing is a joy-killer, as the cost of upgrading them all is way too high for me.

N.A.N.Y. 2012 / Re: NANY 2012 Release: Ethervane Echo
« on: July 09, 2012, 11:29 AM »
Like the previous poster, I joined this site primarily to express my admiration for Echo. It's a fabulous piece of software, head and shoulders above the other clipboard extenders out there. The level of thought that went into the design is really impressive.

Thank you kindly! I apologize for the late reply, I'm just back from vacation.

I do however want to note that I have the same problem posted by Hangdog on January 7th and Silat on April 6th: in Windows 7 x64, for some reason, the status of the tray icon is not saved between sessions. In other words, when the tray icon is set to "Show icon and notifications", it appears, but it will not persist once the user has logged off. On the next login, the icon is hidden again and needs to be reset to "Show". The settings for the tray icons of every other application I'm using persist between sessions; Echo is the only exception. From earlier comments by Tranglos and others I gather this is not a problem in 32-bit versions of Windows, but there does seem to be something about Echo that makes it problematic for the 64-bit version to retain this particular setting, although I can't imagine what it is.

This behavior is governed entirely by Windows. I can try replacing the tray icon library that I'm using with a different one, but I've no idea if this will help.

What would be more likely to help is me switching to 64-bit Windows and the latest 64-bit version of Delphi. I'll move on to Win64 eventually, but the cost of upgrading Delphi and all the third party libraries would go into thousands of dollars, so I'm afraid this is very unlikely. In fact, a move to Win64 will probably mean the end of all development on my side, unless I can continue using the 32-bit version of Delphi.

N.A.N.Y. 2012 / Re: NANY 2012 Release: Ethervane Echo
« on: May 21, 2012, 10:42 AM »
Using the hotkey to open the echo window always opens it in the same position regardless of where it was when I minimized/closed it.

This does NOT occur if I open the window by clicking the tray icon.  I use a dual monitor setup so I want echo on my 2nd mon while I work on my main one.

I like to close windows that aren't used at the moment, but I always have to drag the window over if I use the hotkey.

First, check this setting:

Tools -> Preferences -> Display -> PopupPosition.

By default this option is set to ppAtCaret, so Echo tries to position itself as close as possible to where the caret (text insertion point) is. If this is not possible, e.g. because the currently focused window does not have a caret (a message box, for instance), then Echo pops up at its most recent position.

If this option it set to anything else, change it to ppAtCaret.

This behavior does not depend on how you activate Echo (hotkey, mouse click, etc), but Echo will ONLY reposition itself if it was hidden (minimized) when you activated it. On the same preferences screen there is an option called RepositionOnlyFromIconic, which you can set to False if you prefer.

Please check both settings and see if they help.

N.A.N.Y. 2012 / Re: NANY 2012 Release: Ethervane Echo
« on: May 16, 2012, 10:03 AM »
Doing that, your program is quite happily doing the following -
- Pasting into FF URL textbox
- Pasting into Notepad, EditPadLite
- Pasting into Wordpad, Jarte

So it appears to me that you have solved, what I have not solved.
Could you list the steps that you are taking, between a user leaving their active application, to double clicking a clip.

As I explained in my previous message - Echo does absolutely nothing with regard to other apps and their windows. No matter how you bring up Echo, Echo will lose focus and minimize when you paste a clip. When that happens, Windows gives focus back to whatever application was active at the time you clicked the icon in the SysTray. Echo doesn't know what app that it, but Windows knows it and does the right thing. Echo just waits a short moment to give Windows time to do its work, and then sends a kepyress (Ctrl+V or Ctrl+Ins). Windows is responsible for delivering that keypress to whatever application is now active.

PS Any chance of the single click option ?

I'll have to think about it. It could be very annoying, I imagine.

N.A.N.Y. 2012 / Re: NANY 2012 Release: Ethervane Echo
« on: May 16, 2012, 08:55 AM »
I notice that your program, has the ability to paste directly into the Active application.
That takes a bit of doing, as the clicking of the systray, steals the focus (Active'ness), and Windows does not place the focus (Active'ness) back to the previously Active Window, when the clicked systray program hides itself.
No doubt some API's are involved, to accomplish that feat.
Could you list those for me.

The problem you describe totally applies. There are many ways of activating the app - via the hotkey, click on the task bar icon, click on the "tray" (notification area) icon, alt-tab or mouse click in the program window. AFAIK, there is no solution that can handle all these cases. At least in Delphi, the earliest notifications the app receives about being activated come too late, when the previously active app is already inactive. As you found out, the best you can get in some cases is the tray window, not the previously focused application.

My idea was to give up. I don't try to detect what app was active, since it is doomed to failure most of the time. Instead, I let Windows figure it out, since this is what Windows does anyway. When user pastes a clip in Echo, Echo de-activates and hides itself, then sends a sequence of keypresses. These keypresses go to whatever window becomes active after Echo disappears. This happens to be the application that was active at the time Echo was invoked.

Now, I realize that *theoretically* this may not always be the case. Another app might pop up a window while user is working in Echo. However, I have not experienced this even once in over a year of using Echo myself, and I've had no bug reports to that effect. It helps that in recent versions of Windows inactive applications are not permitted to grab focus.

So far I've only had one issue with my non-solution: applications that actively refuse to regain focus. One such app was reported earlier in this thread. What happens is:

1. App X has focus
2. User invokes Echo and pastes a clip.
3. Echo minimizes...
4. ...but app X does not regain focus, even though it is again the foreground app.

It's important to realize that the problem in (4) happens because app X is specifically designed not to grab focus (and you can't switch to it via alt+tab, for example). Such apps are thankfully rare.

The only thing I could do in this case was to give up again and add a check for the active application, the check that doesn't really work. Well, in Echo it does work if user activates Echo using the global hotkey, but not when Echo gets activated in any other way. So Echo doesn't rely on this value. If Echo is activated via hotkey *and* it can get a window handle that is not the desktop, then it will try to make that handle foreground before pasting the clip. It seems to be working with "Stickies" (the problem app in this case) and doesn't hurt anything, as far as I can tell.

Other than such odd-behaving apps, my non-solution seems satisfactory.

On edit, forgot to add: I know that some similar apps try to monitor the focused window changes as they happen. I haven't even explored this possibility, because my personal "prime directive" is to do as little as necessary to get the desired result. When Echo sits idly in the tray, it is really idle; I don't like the idea of constantly monitoring what other windows are doing. It would require either a very frequently firing timer (which would often miss, anyway) or installing a system hook. Either way is too intrusive for my liking.

Pages: prev1 2 3 [4] 5 6 7 8 9 ... 213next
Go to full version