Glad to see UR evolve to version 6: Can't thank Kinook enough

[cnewtonne]

It has been a journey since 2006 when I first acquired UR license. It has been my daily driver since then and probably till I retire!

If I may pose some questions regarding reelase 6 ...

1) Why the 64 version of UR? Is MS Office compatibility the only reason. For our daily work, should using 64 version add any other benefits e.g. larger database sizes, better performance, more tree items?

2) One of the new features is be able to append to an info items and it states ...

Append to current item option now applies when pasting/dropping, in addition to when auto-importing clipboard content.

I was able to see this feature in action when pasting 'ctrl+v' or using auto clipboard import. But, it did not work when 'dropping' e.g. dragging text from detail pane to the tree. It kept creating more tree items vs. appending to it. Is this not how it should work?


Thanks

[cnewtonne]

One more practical issue during the upgrade process.
I upgraded my existing 32-bit version to release 6 today. Got caught by surprise finding out now that I'm unable to create more tree items because I exceeded the trial version limit.

I purchased an upgrade and according to the site, it may take up to business day to get the keys.

This is not an ideal experience of the end-user. Instead ...

Let the new release work with full features for a week to test it and decide if a user wants to upgrade without any restrictions and gives him/her time to get the keys.

Give the user a warning during install that the upgrade release will be restricted to 1000 tree items.

Thanks

[kinook]

1. Outlook 64-bit compatibility is a big reason but not the only one. It also comes into play in other areas, such as the Item | Show Explorer Menu and Explorer Mode. And it could eventually be a benefit to not have to load the Win32 subsystem or if that is eventually dropped.

2. That is a bug, which is fixed in the latest download.

Regarding the evaluation behavior on an upgrade, that is not so simple considering that the licensing component we're using is no longer being updated and would not easily support this. I think we got your key to you within a couple hours, so hopefully that wasn't too onerous.

[cnewtonne]

Tested the update release. The 'Import: append to current item' behavior is somehow unpredictable ..

This is my test scenario ...
* A tree of one parent and two children.
* Parent has four lines in the editor
* Feature enabled
* Parent is selected in tree

Dragging first line from parent details into child 1, appends the content to the parent itself, but not the child. It did not append the dragged text, but the content of the clipboard, instead.

This is not what I expected.

Also ...
Dragging content from external apps works differently. Using above test, but this time I'm dragging rtf text from an external app.

Looks like I have to actually select the tree item first before I drag text to it. Even though, the tree item gets highlighted by simply pointing the mouse to it giving the indication that it is my target. This is different behavior when this feature is disabled as I'm not required to select the item before dragging to it. Simply pointing to any item in the tree makes it my target.


My understanding is that when this feature is enabled, dragging text (from within UR or outside of it) should always append to whatever the mouse is pointing to similar to creating children by dragging.

[kinook]

The option is append to current (selected) item. We'll have to see if that can be adjusted for the drag/drop scenario.

[cnewtonne]

Dragging to create a new child or appending to existing one, I think should behave the same from a user experience standpoint.

Please consider this change.

Thanks