[Isomorphic]

Apologies for the delay in correcting this one. It's been fixed and is available in today's builds, dated February 1.

[Blama]

Hi Isomorphic,

thanks, I had a look. It working much better now IMHO, especially all the modes work as described, but there are still a few issues (v13.0p_2022-02-01):

• On moving from one item to another with a hover the hover for the 2nd item is not displayed if the old hover is still open
• Links in the hovers in the sample do not work, yet (but there is some docs-link related code in the sample)
• Unexpected items have pin-able hovers:
  
• Pinned hovers content changes on hovering different items:
  

Best regards
Blama

[Isomorphic]

Blama - thanks for the feedback.

Your points 1 and 4 (and probably other misbehaviors, if you really looked hard) are due to the same underlying problem - the EventHandler is still firing off events as usual, while the hoverCanvas is waiting for a mouseOver, and these are intercepting each other in subtle ways.

We'll probably alter to just throw up an eventMask in the interim and will update here shortly when we make that change.

We'll look at 2, and for point 3, "unexpected items have pinnable hovers" - why are they unexpected? Because the content is minimal?

[Blama]

Hi Isomorphic,

regarding 3, yes, that is what I mean. I already thought that this might be hard for you to do automatically. So I assumed a lot of canHover:false or hoverFocusKey:null in fields will be needed. Now I tried

{editorType:"HeaderItem", value:"Attributes for Window component", hoverFocusKey:null, canHover:false},

but both attributes have no effect. Looking it up, this is kinda expected, as these are not present in FormItem and FormItem does not inherit from Canvas like DynamicForm does.

Best regards
Blama

[Isomorphic]

hi Blama

We've made some changes here:

- 1, 2 and 4 have been fixed for tomorrow's builds, dated February 7 or later.
- we'll add full FormItem support shortly, but this won't be in tomorrow's build
- we also made the focusKeyLabel more dense/compact, inline with the rest of the content

We'll update again when the FormItem implementation hits

[Isomorphic]

In fact, FormItem.hoverFocusKey and hoverPersist *will* be available in tomorrow's builds of 13.0 and 13.1, dated February 7 or later.

[Blama]

Hi Isomorphic,

thanks. Using v13.0p_2022-02-07 here I can see that 1, 2, 4 have been fixed.

I can also see FormItem.hoverFocusKey, but this does not seem to have an effect, at least I'm not able to disable the "Pin hover: ..." message for certain FormItems with it.

There is also no canHover, but I'm not sure if you wanted to implement it as well or if one can/should do that with itemHover, but itemHover:"return false;" or itemHover:"false" don't have an effect, either.

Best regards
Blama

[Isomorphic]

We're seeing that setting hoverFocusKey: null on any formItem prevents the focusKey label from showing.

[Blama]

Hi Isomorphic,

I'm trying with this change to the beginning of fields:

    fields:[
        {editorType:"HeaderItem", value:"Attributes for Window component", hoverFocusKey:null, canHover:false},
        {editorType:"SectionItem", sectionExpanded:true, value:"Header",
            itemIds: ["showHeader", "title"], hoverFocusKey:null, canHover:false},
        {name:"showHeader", type:"boolean", labelAsTitle:true, defaultValue:true, hoverFocusKey:null, canHover:false},
        {name:"title", type:"text", width:180, hoverFocusKey:null, canHover:false},

There is still a hover with "Pin hover: Press f2" for field SectionItem. Fields showHeader and title are working fine.

How is one meant to disable hovers for a field at all (last question in #22)?

Thank you & Best regards
Blama

[Isomorphic]

Ah, that's an oversight - SectionItem is a CanvasItem, and DynamicForm.setHoverFocusKey() propagates its value to the canvas child of CanvasItems. You could suppress the label for SectionItems by setting hoverFocusKey: null on item.canvas.

You should see it working as expected on regular formItems.

We'll correct the bug for tomorrow's builds.

[Blama]

Hi Isomorphic,

this does still happen with the code from #24 and v13.0p_2022-02-10/SNAPSHOT_v13.1d_2022-02-10.

Best regards
Blama

[Isomorphic]

Sorry for the delay - this change has now been committed and will be in tomorrow's builds.

[Isomorphic]

On your question about how to prevent hovers for an item: in general, you just set a null prompt, and/or don't return a value from itemHoverHTML().

In this sample, however, there's an override that always provides titleHoverHTML() - so, in this case, you can prevent a hover for a certain item by having titleHoverHTML() return null for it.

Note that it looks like this mechanism also doesn't function for CanvasItem, SectionItems in this sample - we'll look into that and update here if necessary.

[Blama]

Hi Isomorphic,

hoverFocusKey:null is now also working for SectionsItems using v13.0p_2022-02-24.
The issue you mention in #28 is still open though.

titleHoverHTML : function (item) {
        return null;
    },

does not work for SectionsItems, but for the other FormItems in the sample.

Best regards
Blama

[Isomorphic]

Hi Blama

Thanks for the feedback - we're going to add something like FormItem.canHover, as you suggested, since FormItems can show hovers for various reasons/from various sources.

We'll update here when those APIs arrive.