dconnet

FYI: CEF3 is the browser framework in which the editor runs (and any other embedded web page we show). It's not the editor itself. (I don't know what the editor is based on - I write C++ not javascript!)

Actually, it doesn't. Once the installer is done, it automatically launches the program (which want to register). Just quit. You're done.

Simpler - Change the setting in Options, completely close EN, delete the database (assuming no local notebooks), restart. No need to uninstall/install.

Sorry - regedit was opening to the last path... Evernote6 is where it goes for our internal builds (to keep it separate from production). `HKEY_CURRENT_USER\Software\Evernote\Evernote\EvernotePath` is the correct path

Resetting the first account is easy - you can do it in the Options dialog. When you do this with the 2nd instance, it will have an issue because the database is already there - for that, you'll need to directly edit the registry and change the HKEY_CURRENT_USER\Software\Evernote\Evernote6\EvernotePath setting (before running EN).

That sounds like a bug we fixed a while ago - the app was remembering its last state - minimized - and restarting that way. Try what @CalS suggested - that ensures the data is properly flushed to the registry.

"Launch Evernote at Windows login" in the Options, General page,

Can you access Evernote (web app) using Internet Explorer? That's what we use as the connection layer. (I have to connect to VPN at work and have no issues with syncing)

Yes. We upgraded from CEFv1 to CEFv3. It was painful - the programming model is completely different. (it's also why you see more Evernote processes in task manager)

It sounds as though you have a monitor set to a high DPI. We are not multi-monitor aware. So Windows will render at the high DPI and scale down to the 100% - hence blurry.

On 32bit systems. On 64bit systems, the default is "C:\Program Files (x86)\Evernote\Evernote" (because we're still just a 32bit app)

Actually, we use the internal nightly builds. pre-pre-pre-beta.

The default hotkey we use has been usurped by Microsoft. Win+Shift+S is now used by Microsoft's Snipping tool. I know of no way to turn that off. The only option is to pick (and assign) a different hotkey in our Options dialog.

I can completely agree with this. (I used to work on MindManager)

In the registry, set "SetNewNoteFocusToTitle" (DWORD value) to 0.

Huh. It looks like the Options dialog does not work on XP. (We are currently reworking the Options dialog, but that won't be done for a while) While we haven't killed support for XP, I would in no way say we actually support it. We're not likely to fix any XP-only bugs.

Possible (probably!) related: https://esupport.trendmicro.com/en-us/home/pages/technical-support/1104301.aspx

Well - kind of - but it will want to move the current database there, not use the one that is already there. The only way to do that in the past was to hack the registry. But StoreApps make that impossible. What you could try would be to do a complete backup of the custom location, point the StoreApp to the existing custom. Tell EN 'yeahyeahyeah'. Then after it finished, close EN (completely) and restore your backup. This is no different then having a custom location on a new computer - EN has never had the ability to forget the current database and use a different one (except, as noted, by hacking the registry)

Not quite. It will not touch the existing install. As long as you're running a current version (6.x - post database move), it will utilize the existing database files. If you have moved the database to a custom location, it won't find it (no access to normal-desktop registry). Both versions will not run at the same time (we have never allowed multiple instances for the EXE), so that's not an issue. But you might easily get confused which one is running. Uninstalling the desktop version will not affect the store version. And uninstalling the store version will not affect the desktop one.

The 2 versions use the same (exact) binary. But there are some runtime differences - WinStore can do tiles and notifications - enscript does not work with WinStore version - WinStore is easier to update - no MSI installer - Some options that make no sense in the Store have been removed - for instance check-for-updates. Other than that, I'm not aware of any other differences. (And I'm who storified it)

Known bug. A fix is in the pipeline.

You need the desktop version of OneNote installed. Not the Metro/ModernUI/UWP/name-of-the-day version. It also needs to be running when you do the import into EN.

You misunderstand. When you upgrade an existing installation, the old version is uninstalled (I'm not talking about an explicit uninstall by the user). That is the phase during which the shortcut is cleaned up. That's how msiexec works. The programs you mention may very well be scheduling the removal after the install. Or they may be doing "bad" things. Unless we can figure out how to safely to an upgrade where we first install and then uninstall, this behavior will not change. We have no plans to reverse engineer how MS stores the shortcuts (yes, I know where they live) and perform undocumented/unsupported actions that are sure to cause issues in future versions of Windows.

How's that? Unless Evernote's application name changes or its file path changes, the "old" pinned item will still point to something. For those who manually pin Evernote to the taskbar, it is most likely pointing to C:\Program Files (x86)\Evernote\Evernote\Evernote.exe unless Evernote is intervening and doing something else and pointing to what, the registry? C:\Users\%user%\AppData\Local (or Roaming)? Because the MSI uninstall process cleans up the shortcut (during RemoveShortcuts). During an upgrade, the old product is uninstalled and then the new one is installed. (If you know MSI terminology, we schedule RemoveExistingProducts before InstallInitialize) When you pin the app, we do not intervene. The _only_ API Microsoft provides for interfacing with a pinned item is IStartMenuPinnedList::RemoveFromList. I think that name is descriptive enough that it's obvious what it does... The _only_ legal way to get the shortcut to stick on upgrade is to change the installer to first do an install and then uninstall the old product. This has it's own set of issues, especially in an already released product. Bottom line, this is not going to change unless Microsoft changes msiexec.

Microsoft frowns on any installer messing with the task bar (http://blogs.msdn.com/b/oldnewthing/archive/2003/09/03/54760.aspx). I believe (tho I haven't looked closely) that we do have some special cleanup code to remove the existing shortcut. Because if you don't, then an uninstall/install (or upgrade) would leave the old pinned item pointing to nothing. (I see that with other programs I use) Also note http://msdn.microsoft.com/en-us/library/dd378460(VS.85).aspx, specifically "A small set of applications are pinned by default for new installations. Other than these, only the user can pin further applications; programmatic pinning by an application is not permitted."