Jump to content

Jason Miller

Employee Alumni
  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Jason Miller

  1. So it's not exactly indexing in this case, that happens when doing an upgrade and notes are migrated to a updated DB - our normalization process (which just cleans up the note structure behind the scenes) is doing this, however the note needs to be downloaded and then the process run (when you switch notes) for it to finally kick in (which can appear just as slow as indexing - depending on the normal of notes, note size etc. Does this mean it is starting to behave correctly for you (after "indexing" takes place) or are the tables still a problem?
  2. If you have the new table UI options (for example when you are in a table dots appear about columns on top or rows on the left, and/or you see a button that gets you a floating menu with options for background color and such) then you are in the new tables - and once you move the table columns they should stay where you put them. If you don't see the new table features, then the system is getting confused. When I adjust the column width on the previous ENEX file you shared they stay when I switch notes (note helpful for you at the moment probably) This the note you are currently working
  3. No when you adjust them, they should say adjusted - if you right click inside a table and go down the "table" option in the menu that appears is there an update table option?
  4. Ok, so the new fixed width feature of the new tables messed up the formatting (column width) requiring re-adjustment - unfortunately I don't a quick solution for that - though once manually adjusted again, they will stay that way - sorry
  5. I think I am a big confused, the tables when I load the ENEX file don't seemed messed up (attaching a screen shot) - I am not paying attention to the right thing? (or if open a problem note, leave it and return does it get fixed or more messed up?
  6. We put in logic to help prevent this, obviously you have tables that aren't being handled correctly - can you share such a note so Dev can take a look at it and make our table protection logic better?
  7. Not sure what I can hep with then. Do you have a note(s) that can be shared that show the broken behavior, so I can take the info to Dev?
  8. Is this a nested table? (and obviously something is getting through our protect old tables, logic) do you happen to have a problem note you can share so our dev folks can take a look at what is going on?
  9. Yes, not sure if that causes you problems in the short term (the note is on my list to sanity check (again) as 6.8 gets closer to going out. To Confirm we didn't break it again.
  10. Yes, a known bug and has been marked to be fixed sooner rather than later, however I don't have an ETA yet.
  11. So there is a fix for this (tested by me being able to via the note like in your example) the fix won't make the 6.7 Release due to additional testing going on, it will be in 6.8
  12. Technically this isn't for bug reporting and tracking, it is a user forum for discussion and comments about our betas and new features. I shared your info with other Mac folks who work more with syncing issue than I do for better feedback on the issue you are encountering with syncing on a busy network. Since the network is busy, conflicts can happen, however updates are being made to the sync engine to help with this.
  13. That is something in the note that is causing a problem with updates to the edit - is this a note that is safe to share with our developers so they can see what is going on?
  • Create New...