dconnet

FYI: We just got a Go and I was able to reproduce with 6.17.5 which is what downloaded from the store. And then, lo and behold!, today Windows Update kicked in and upgraded me to Version 1809, build 17763.316 - AND EN WORKS! (I also clicked 'check for updates' and saw a bios update happen)

The first message should be pretty obvious... The path to H: isn't there. The second one means you're on a network or removable drive. Highly not recommended because of how sqlite file locking works.

If you can't open EN (even the login screen is enough) to get to options, the database path is stored in the registry:

HKCU/Software/Evernote/Evernote/
EvernotePath="fullpath"

Evidently, the original MSI that gets cached in Windows\Installers must have been deleted. (Some "cleanup" tools do that - if those files are deleted, you can't uninstall those associated programs) You need to get the 6.11.2 installer and run a repair. You'll then be able to either uninstall or upgrade. (I would also clean up any files in "%TEMP%" just in case the bootstrapper is getting confused)

New CEF releases (which I'm pretty sure we had when this problem became more prevalent) are always fun. Especially since the hardware we have doesn't exhibit the issues all of you see...

On 2/1/2019 at 7:01 AM, Dave-in-Decatur said:

Will it still be possible to use the Win key if desired?

Yes. You can always set it to whatever key combo you want.

FYI: In a future update (currently targeted at 6.18.Beta2), the default hotkeys will be updated to remove any Win modifiers.

These will be:
CreateNewNote: ctrl+alt+N (current default)
FindInEvernote: ctrl+shift+F (new, current win+F)
CaptureScreen: ctrl+alt+S (new, current win+S)
CopySelection: ctrl+shift+alt+A (new, current win+A)
PasteClipboard: ctrl+alt+V (current default)

2 hours ago, jefito said:

But maybe if the RegisterHotKey() happens in the tray process (guessing here)

Yes.

15 hours ago, Sam_CLE said:

how did they hijack it if it was working with previous versions of evernote??

Windows did not originally use Win+A. I'm not sure what version of Windows that came in with, but it's recent.

We have a bug in our backlog to change all the hotkeys to remove the Win modifier. In the meantime, users are free to pick whatever key combination they want in the Options dialog.

1 hour ago, ConnieN said:

Nothing happens when I click the icon

Use Task Manager and see if the Evernote process is "stuck". Kill any Evernote/EvernoteTray/EvernoteSubprocess instances (or reboot Windows). The shortcut should work after that. (Sometimes EN gets stuck while closing - but the window has gone away so it looks like it's gone. But it's still enough alive that the mutex prevents another instance from starting.)

57 minutes ago, jefito said:

is there an API to determine who owns a particular hotkey?

No. All you can do is try to register it. If it fails, someone has it. The way people figure out "who" has it - use taskmgr and kill processes until the hotkey is released.

Oh great. Another of our default hotkeys has been hijacked by Microsoft... sigh. (Whoever registers the hotkey first gets it. Windows has an advantage there.)

> did they bother research what windows built in shortcuts are? 

Yes. Yes, we did. And then MS released an new version of Windows and here we are.

Try disabling hardware acceleration: Tools -> Options -> General -> "[ ] Enable Hardware Acceleration"

Sorry, no. We don't give out internal details like that or scheduling info. (I remember creating the bug/feature-request when I stumbled over an MS blog "Supporting “launch at startup” in a desktop app converted with the Desktop Bridge")

It's in the backlog. Windows Store apps are ... um ... different. So the startup doesn't work the same.

Because we haven't fixed it yet. We're actively working on it, but there's many moving parts and things we thought for sure would work caused havoc in other areas.

Hardware acceleration can also be changed via the Options dialog (on the General page).

I shudder to implement this because of ambiguity (yes, I'd be the one on the Windows platform)... You realize %APPDATA%.txt is a valid windows file name?

As far as I know, we do not support environment variables in a link. (For one thing, they're not cross platform so that link could not work on any platform other than Windows)

Thanks - this is a known issue. We have a bug tracking it (well, the bug is actually for Russian, but it's the same thing!)

6 minutes ago, rdenzel said:

Strangely, it says (32 bit) when this is a 64 bit system.

This is not surprising. We're a 32bit app.

Can you detail how you got into that loop? I just tried (with the current beta 6.17.1) and the message is displayed once. I can then edit the title. It works this way both when the new note is created in a window and when it isn't.

18 hours ago, EdH said:

Windows just got real DarkMode support with 1809

For UWP (Windows Store) apps only. We're an old-style Win32 app (even the WinStore version of EN is still considered Win32).

17 hours ago, EdH said:

I do find it odd that the Windows client is the only 32bit client you have now. All the rest are 64 bit.

It's probably the only 32bit OS we support anymore - So even if we had a 64bit version, we'd still have to have a 32bit one...

2 hours ago, RL7836 said:

Is there a rough timeline for a 64-bit Windows-based Evernote?

No. At least that I'm aware of!

Sorry, we don't support changing application accelerators. The only things that can be changed are the global hotkeys (those that are listed in the Options dialog). 

If it was one of the EvernoteSubprocess processes, then it's Chromium.