Search the Community
Showing results for tags '64-bit'.
Found 2 results
I've been trying to keep my Evernote backed up, and attempting to do so in multiple formats to ensure that I have something that can be parsed/imported later. With 4000 notes, including a large number of scanned images and PDFs, the current 32-bit Evernote application crashes when exporting all notes in "Single-page html" or web-archive/mht. It took me a little while to track down what was happening, but essentially Evernote is consuming a large amount of RAM during exporting those formats. The used memory increases until it gets to about 3.5GB and then crashes. The error messages in the activity log file look like this "date/time [pid] CBuffer: Failed to allocate xxxx bytes of memory." There should be a few of them before the app crashes. The computer has 32GB of ram, and could certainly support a temporary increased usage to facilitate the export. A 64-bit version would be nice to avoid these types of limitations. Thanks Keith
I've run into several (usually minor) bugs in the interface that I wanted to bring to your attention. I scanned the section and didn't see any of these mentioned previously. For reference, my platform is: Win 7 64 bit Evernote 184.108.40.20660 The specific issues are: Moving Tags With Children Start with tags A, B, C, and D. Tag A has subtags A1, A2, and A3, Tag B has subtags B1, B2, B3 and Tag C has subtags C1, C2, and C3. If you drag A onto D, the subtags are moved properly (stay as subtags). If you click on A, ctrl-click B (to highlight both), and drag to D, subtags are moved correctly. However, if you click on A, shift-click on B, then drag the highlight to D, the children of A (A1, A2, and A3) do not remain children of A. Instead, they become children of D. Similarly if you select A, shift-select C (also including , then drag to D, the children of A and B are both "lost" and become children of D. My interpretation is that the the shift-click is selecting all items between A and C -- including children -- and moves them. The interface should only affect tags at the *current level* in the hierarchy and trigger a move on them. [*]Removing Tags When you mouse-over a tags, it shows an (X) on the right end of the tag. This implies that clicking the X (or perhaps the tag entire) should remove the tag. It does not. As a fall-back, you can right click on visible tags and select the "remove" option. However, tags that are not normally visible on the screen (that can only be accessed using the down arrows) do not respond to a right click and cannot be removed this way. I'm aware that you can go the long way around with a Ctrl-Alt-T but tag behavior should be standardized. [*]Adding Tags Create a new note. Click on the "Click to add tag..." area. Add a tag and press enter. The tag is added and your cursor is placed in the region to add a new tag. Repeat this process until the area is full. The last time you hit enter, there is no space for a new tag, but it automatically pops up the "Add tags" window. This is a continuation of the previous behavior. However, if you hit enter from the add tags window, the window doesn't pop back up. This strikes me as inconsistent behavior if I'm expecting to type a tag, hit enter, and type a new tag. The precise length of a tag (i.e. whether or not it causes the UI to run out of space) shouldn't change the UI behavior. One alternative is to prevent the tag-chainning behavior in the regular UI. This won't reduce the power of the UI since multiple tags can be entered if they're separated by a comma.