[Announce] node-red-contrib-ui-svg (final beta) UPDATE V1.2.1

I've seen that behaviour as well - I wondered what was going on at first (thought Node-RED had frozen).

@Steve-Mcl - no - never seen that.

1 Like

@mtoko, @dynamicdave

Is this the same thing I reported on V1.beta4?

Can you list steps to reproduce this?

Can you look in console.log see if you have the same error?

It may well be our node causing this issue (likely) or something node-red is not handling (less likely but possible).

If you can re-produce this consistently we might be able to figure it out.

1 Like

@ Steve-Mcl
Steps
1.) Add SVG graphics node on new flow
2.) Select SVG graphics node and open DrawSvg editor
3.) Make a small edit in DrawSvg editor and save
4.) Deploy changes in Node Red editor
5.) Cannot select any node in Node Red editor on any flows
6.) Cannot open any node config on any flow when double click any node
7.) Work around is to refresh Node Red editor and all works fine again
I have attached Console log (hope this is what you want)
ThankssvgLog.txt (10.1 KB)

Thanks for feedback.

Could you try the followng (please follow exact steps)...

  1. refresh editor
  2. ensure you can click items.
  3. Open the svg node & change something
  4. deploy
  5. refresh browser
  6. try your steps to see if the problem still exists.

NOTE...
In your log I see Uncaught TypeError: Cannot read property '_focusTabbable' of undefined - that is the same as the error I seen too.

Uncertain what is causing it.

It would seem likely that since you have the SVG node installed & you are witnessing this issue the problem is related. However I am unsure if there is something node-red is not handling/checking (regardless of cause).

@ Steve-Mcl
I have followed your steps and the issue remains the same, it can still be used but it is necessary to reload the Node Red editor after any changes in the SVG graphic node
See this video

Hey Steve (@Steve-Mcl),

I couldn't reproduce the problem on my test system, which still was running an older Node-RED version. So this evening I have upgraded to Node-RED 1.0.1 and now indeed I get the same error...

Found on StackOverflow that the problem is caused in some jQuery versions, when a popup dialog is being opened inside another popup dialog. That is indeed the same situation we are dealing with here: we open the first popup (i.e. our node's config screen) and from there we open another popup (i.e. the DrawSvg editor).

So did a quick test by putting a breakpoint in our oneditsave (i.e. just before our config screen popup is closed, and we are returning to the flow editor):

  • When I change something in our config screen but I don't open DrawSvg, then $.ui.dialog.overlayInstances is 1 (which means 1 popup open).
  • When I change something in our config screen and I open DrawSvg, then $.ui.dialog.overlayInstances is undefined!!

The problem 'seems' to be solved when I add this:

oneditsave: function() {
   ...
   $.ui.dialog.overlayInstances = 1;
},
oneditcancel: function() {
   ...
   $.ui.dialog.overlayInstances = 1;
},

But of course it isn't really a scientific approach. Because I don't know how this will behave in future jQuery versions. However it is the only approach I can think of at the moment ...

[EDIT]: I see now that the DrawSvg window is never destroyed. Could that be the cause?

Anybody a suggestion?

P.S. @mtoko: you recording is by far the most beautiful incident description that I have ever received from a end user :+1:

It 'seems' to me that the problem is also solved when I destroy the (DrawSvg popup) window after it has been closed:

buttons : {
   "Yes":function(){
      saveSVG(function(){
      //onSuccess
      window.svgEditorDialog.closeConfirmed = true;
      window.svgEditorDialog.dialog("close");
      window.svgEditorDialog.dialog('destroy');
      messageBox.close();
      })
   },
   "No": function(){
      window.svgEditorDialog.closeConfirmed = true;
      window.svgEditorDialog.dialog("close"); 
      window.svgEditorDialog.dialog('destroy');
      messageBox.close();
   },
   "Cancel": function(){
      window.svgEditorDialog.closeConfirmed = false;
      messageBox.close();
   }
}

I'm more confident with this second solution. Will test it a bit more, to make sure it wasn't a lucky shot...

I found the same thing Bart, did some tests (and broke some stuff in the process). just didn't get time to finish the fix so good stuff. I agree with the 2nd option.

1 Like

@mtoko, @dynamicdave: It is now available on Github (as version 1.0.1).

If you remember Bart, this was the only way I could get DrawSVG to be stable (I said I didn't like it but it worked!). And if you recall, I challenged you to find a better way :joy::joy::joy:

@mtoko, @dynamicdave: Had some chit chat with @Steve-Mcl and seems this fix makes things even more worse. So I have removed it again from Github. Due to the complexity and our limited spare time, this will most probably take some time to get solved...

:vulcan_salute:

Hi folks,

Good news for the SVG lovers in the Node-RED community, since we proudly announce our second beta version (1.1.0) :champagne: :partying_face: :champagne: :partying_face:

But to be honest, due to private issues I had very few spare time for this beta release. So most credits go to my partner in crime @Steve-Mcl !!!

A summary of the major changes (beside a series of smaller bugfixes and enhancements):

1 - DrawSvg as preferred input

Joseph Liard (the author of DrawSvg) is currently implementing our feature requests, to integrate DrawSvg even better into Node-RED. Looks very promising, so we have changed the initial mindset of this SVG-node: instead of entering the SVG source manually (and optionally open DrawSvg afterwards), now we advise to draw in DrawSvg (and optionally change the SVG source manually afterwards).

To highlight that DrawSvg is the preferred way to go: we have removed the small DrawSvg button (below the SVG source editor), and instead added a new "Editor" tabsheet containing a large button:

P.S. As you can see in the above demo, a link to the 'Settings' tabsheet is displayed when no editor URL has been specified (as an extra help for the issue that @dynamicdave had registered above).

P.S. Also thanks to @dceejay for assisting us with the CSS issues!!

2 - FontAwesome support in DrawSvg

Joseph Liard has already been so kind to add FontAwesome icon support in his online drawing editor. This allows you e.g. to create very easily a floorplan of your house:

svg_beta2_demo

The above demo shows also how to customize the look-and-feel of the icon (e.g. change the color), but also how to apply an identifier ("cam_kitchen"). That identifier can be used later on to interact dual-way with your icon (i.e. via both input and ouput messages), similar to the interaction with other SVG elements.

3 - Unresponsive flow editor fix

Users like @mtoko had reported that the flow editor became unresponsive (i.e. you couldn't click on any other node), after leaving our config screen. This problem should be solved now ...

--- WHAT IS NEXT ---
The major required functionality is now available in this current beta version, so we will try to publish a final version on NPM soon. Perhaps we might fix one or more smaller bugs next week, but we don't expect huge changes anymore. So it would be nice if this beta could be tested as much as possible!

Have fun with drawing in Node-RED!
Bart & Steve

6 Likes

I can use exactly this for an upcoming project. Where can I find the demo flow? I looked on the NR forum and Git. I didn't see this one.

edit: It is the data driven HMI demo

Hi Joe (@jmorris644),

You can find the nice demo from @Steve-Mcl in the "import" menu.
For Node-RED version 1.0.x it can be accessed like this:

svg_example_flow

1 Like

Thanks Bart! I didn't even know the demo area of import existed.

The layout that @Steve-Mcl created is exactly what I will be needing. But the flow was not quite what I had imagined by being data driven.

I need to monitor about 100 remote IOT devices with both architectural health information but internal user information as well. Also the number of devices may change upon implementation so I do not wish to hard-code the boxes in the node.

At a high level, if I needed to create the boxes with the data and the ability to drill down just like @Steve-Mcl did, but totally from outside of the SVG control, what would be the best process for doing that?

I hope there is a little clarity to my question.

Joe

For a demo, demo data is faked. What did you expect? If you want real data to drive it then replace the demo data :+1:

You want something to draw boxes in a 4x2 format that drills down but you don't want to hard code them? How do you imagine such a program could guess what you want? Please elaborate.

I am struggling to understand what you mean? From outside? Our control is for simplifying the creation and manipulation of SVG graphics - not for controlling things outside of itself?

1 Like

Sorry, total confusion.

So lets say that I want the boxes lie you have them with certain names and certain data and allow drilldown to display more data within a box. Each box could represent a device in the real world that is being monitored. Based on the state of the real-world device the box would change color.

Now, lets say that when we implement the flow solution that contains the SVG node that we do not know how many real-world devices exist or the names of those devices.

Is there a way to dynamically build the SVG source without any of it being hardcoded in the node itself?

I see that the node input allows me to set attributes of elements, but can I dynamically create the elements themselves?

I hope this is more understandable.

Thanks

Joe

In Win10/Chrome the behaviours are not working for me (title bar not going to full screen, and station 10 click just flashes up page 2 then drops back to page 1).