• 0 Posts
  • 43 Comments
Joined 17 days ago
cake
Cake day: January 2nd, 2025

help-circle
  • I’d stop wasting time trying to make it work. Simply save your spreadsheet (you are saving it early, often, and keeping dupliicates, right?), and just copy/paste the file into an email.

    At one point I supported Office for Microsoft, and while they’d never admit it, this process for embedding files has alway been a little wonky (directly from one app to another). Grabbing the file and pasting it eliminates the risk of either app causing a problem because the OLE registration isn’t perfect, by using a file system path to the object.

    I believe you can paste into Outlook a sheet as a table this way, if that’s what you’re trying to do. Not something I’d do, because, again, this kind of stuff has always been a little less than perfect. Attached files seem to have fewer issues.

    Edit: I currently have one machine where URLs in docs (Word, excel, Publisher, Project, Onenote) can’t be launched, an error says “Administrator has disabled this feature”. I gave up trying to fix it (and remember, I supported Office, I know how this stuff works, I have notes from years ago about which reg entries handle this stuff). Now I just copy the URL. It’ll get fixed when I refresh this machine.






  • Documentation has been mentioned already, what I’d add to that is planning.

    Start with a list of high-level objectives, as in “Need a way to save notes, ideas, documents, between multiple systems, including mobile devices”.

    Then break that down to high-level requirements such as “Implement Joplin, and a sync solution”.

    Those high-level requirements then spawn system requirements, such as Joplin needs X disk space, user accounts, etc.

    Each of those branches out to technical requirements, which are single-line, single-task descriptions (you can skip this, it’s a nice-to-have):

    “Create folder Joplin on server A”

    “Set folder permissions XYZ on Joplin folder”

    Think of it all as a tree, starting from your objectives. If you document it like this first, you won’t go doing something as you build that you won’t remember why you’re doing it, or make decisions on the fly that conflict with other objectives.