Development Environment Toolbar

[JDave]

Jumping out of the Connector Pane thread, I am wondering if there is any interest in making a Development Environment toolbar. Some varying efforts and ideas are out there. But I suppose some minimum requirements would be:

• Plugin architecture to allow adding and removing tools.
  
• Shortcut keys to invoke tools.
  
• Monitoring of what the Active VI is
  

Maybe this would be better done as an OpenG effort. Or maybe as a Coding Challenge effort. But there are some neat ideas out there that deserve to be plugged into our IDEs. And maybe if the idea is cool enough, NI will allow tools to be added to the native toolbar. Wouldn't that be a dream...

Are there any drawbacks to this obviously involving scripting and thus features that are not supported by NI?

What are your ideas on such a toolbar?

David

[gb119]

I wrote my own development environment toolbar for my own use - it didn't have plugins or any fancy key bindings, but I did include things like the XNode manager and some of my various scripting hacks like a "clean-up all wires" tool, a "wire up all possible tunnels" tool, a "re-link all badly linked subvis" tool, a "show node terminal locations and order" tool, and a "find tunnelling error wire and rewire to case selector" tool (my favourite for making my sub-vis more LAVA code repository friendly....)

Unfortunately other priorities (undergraduates mainly) have gotten in the way of my LabVIEW coding recently !

QUOTE(JDave @ Oct 18 2007, 10:37 PM)

Jumping out of the http://forums.lavag.org/index.php?showtopic=9297&view=findpost&p=37300' target="_blank">Connector Pane thread, I am wondering if there is any interest in making a Development Environment toolbar. Some varying efforts and ideas are out there. But I suppose some minimum requirements would be:

• Plugin architecture to allow adding and removing tools.
  
• Shortcut keys to invoke tools.
  
• Monitoring of what the Active VI is
  

Maybe this would be better done as an OpenG effort. Or maybe as a Coding Challenge effort. But there are some neat ideas out there that deserve to be plugged into our IDEs. And maybe if the idea is cool enough, NI will allow tools to be added to the native toolbar. Wouldn't that be a dream...

Are there any drawbacks to this obviously involving scripting and thus features that are not supported by NI?

What are your ideas on such a toolbar?

David

[Mark Balla]

QUOTE(Gavin Burnell @ Oct 18 2007, 05:01 PM)

I wrote my own development environment toolbar for my own use - it didn't have plugins or any fancy key bindings, but I did include things like the XNode manager and some of my various scripting hacks like a "clean-up all wires" tool, a "wire up all possible tunnels" tool, a "re-link all badly linked subvis" tool, a "show node terminal locations and order" tool, and a "find tunnelling error wire and rewire to case selector" tool (my favourite for making my sub-vis more LAVA code repository friendly....)

Unfortunately other priorities (undergraduates mainly) have gotten in the way of my LabVIEW coding recently !

Any chance you could post these or submit them to the CR.

I am especially interested in the clean up all wire tool

Thanks

Mark

[gb119]

QUOTE(mballa @ Oct 19 2007, 06:15 AM)

Any chance you could post these or submit them to the CR.

I am especially interested in the clean up all wire tool

Thanks

Mark

Already there - http://forums.lavag.org/downloads-file87.html

(the cleanup all wires was a bit of example code, but I think it you search on LAVA you'll find other people's versions as well)

[Norm Kirchner]

I am definetly on board with pushing NI to allow us to easily plug in our own additions to the Dev environment. I can't count the number of times I've created floater utilities w/ 1 button to accomplish something. One that may make it to the CR is a tool to auto align the label of input controls to be justified to the right edge of the control. I know that you can now have LV auto do it but that is to the same location for both controls and indicators and for me, on the BD, controls label right just. indicator label left just.

But to be able to easily add this in would be great, cuz finding out what the active VI is, is still a little bit of a hack.

Actulally the new LLB Viewer is written in pure G and has the possiblity of creating your own plugins. Just watch the NI week 07 videos and I'll give you the passwords to get into it. I would have to say that the code is 'Super Spiffy'

[Michael Aivaliotis]

QUOTE(Norm Kirchner @ Oct 19 2007, 05:51 AM)

I am definetly on board with pushing NI to allow us to easily plug in our own additions to the Dev environment...

You guys have to stop thinking that way. You want something, build it yourself. You could probably crank out something in a few weeks that would take NI several years to release. Do whatever you have to do to make your life easier.

[Michael Aivaliotis]

QUOTE(Norm Kirchner @ Oct 19 2007, 05:51 AM)

I am definetly on board with pushing NI to allow us to easily plug in our own additions to the Dev environment...

You guys have to stop thinking that way. You want something, build it yourself. You could probably crank out something in a few weeks that would take NI several years to release. Do whatever you have to do to make your life easier.

[Norm Kirchner]

QUOTE(Michael_Aivaliotis @ Oct 20 2007, 06:39 PM)

You guys have to stop thinking that way. You want something, build it yourself. You could probably crank out something in a few weeks that would take NI several years to release. Do whatever you have to do to make your life easier.

It's true. We should just get rid of the event structure and come up w/ our own management scheme that runs in the background and uses occurences to fire off our own 'events'

Of course we'll do it ourselves, but wow isn't it nice to have it integrated too. And it's good if we make something ourselves and NI eventually picks up the ball, that way they already know what we want. Look @ the Tree Control toolkit, I'm sure it will make it's way to the dev environment soon enough

[JDave]

QUOTE(Norm Kirchner @ Oct 22 2007, 07:42 AM)

Of course we'll do it ourselves, but wow isn't it nice to have it integrated too. And it's good if we make something ourselves and NI eventually picks up the ball, that way they already know what we want.

That's what I was thinking. :thumbup:

I have some code that I have started for a toolbar. But I was wondering how other people have implemented or thought about implementing development environment tools.

For instance, I made a separate Daemon VI to monitor VI Activations and keyboard events (polling the keyboard) to allow for multiple floating tools all getting event notifications.

What information would you pass to your tool upon invoking it from the toolbar?

Would you leave it floating free, or dock it to the monitor edges, or to a VI window edge?

I displayed my tools in a 2D array of pictures. Is there another way that someone has tried or thought about? Is there any ingenious way to separate tools into categories?

P.S. - I will be looking for that Tree Control toolkit to be integrated

[Ton Plomp]

QUOTE(JDave @ Oct 22 2007, 06:05 PM)

What information would you pass to your tool upon invoking it from the toolbar?

I used to mimick all related mouse events:

• Mouse Enter
• Mouse Down
• Mouse Move
• Mouse Leave
• And I triggered on active VI change events

So basiccally I sended all the info from Mouse xxx events.

I think with my current knowledge of XControls we should do them as XControls.

Ton

PS Here's my previous version

[JDave]

QUOTE(tcplomp @ Oct 22 2007, 09:48 AM)

I used to mimick all related mouse events:

• Mouse Enter
  
• Mouse Down
  
• Mouse Move
  
• Mouse Leave
  
• And I triggered on active VI change events
  

So basiccally I sended all the info from Mouse xxx events.

Thanks for pointing me to your code. I remember when you posted it, but I don't think I ever took a good look at it. When I was looking at the project, I noticed that it doesn't have any examples of what you would do on a Mouse Enter/Move/Leave event. What were you planning to have a tool do if you entered its button on the toolbar?

When the Active VI change, the toolbar moves if 'stuck' to a VI. Is this what you meant by triggering?

QUOTE(tcplomp @ Oct 22 2007, 09:48 AM)

I think with my current knowledge of XControls we should do them as XControls.

The code you uploaded has a single picture control. Were you evisioning having a single XControl to replace the picture control, or an array of buttons that are each XControls?

Up until now I have viewed XControls as helpful if you have a complex FP object that you want to use in several situations. It encapsulates the functionality so you can replicate it else where. I have not dabbled in XControls at all, so could you please help me see how they would be beneficial here?

Thanks for the response!

David

[Ton Plomp]

QUOTE(JDave @ Oct 22 2007, 08:02 PM)

When the Active VI change, the toolbar moves if 'stuck' to a VI. Is this what you meant by triggering?

No I ran a VI (By Ref) if another VI was activated

QUOTE

The code you uploaded has a single picture control. Were you evisioning having a single XControl to replace the picture control, or an array of buttons that are each XControls?

Up until now I have viewed XControls as helpful if you have a complex FP object that you want to use in several situations. It encapsulates the functionality so you can replicate it else where. I have not dabbled in XControls at all, so could you please help me see how they would be beneficial here?

What I did was having for every Event a special VI that I ran by-ref. I had quite some problems with typedeffing VIs.

This would not be simplified with XControls, but it's something that better suits me right now.

I would have an XControl for every button, and maybe one XControl for every bar.

Ton

[JDave]

QUOTE(tcplomp @ Oct 22 2007, 01:35 PM)

No I ran a VI (By Ref) if another VI was activated

What I did was having for every Event a special VI that I ran by-ref. I had quite some problems with typedeffing VIs.

This would not be simplified with XControls, but it's something that better suits me right now.

I would have an XControl for every button, and maybe one XControl for every bar.

Ton

That makes sense. The way I started writing my toolbar is quite different so it took me awhile to follow what you were doing.

I wrote mine such that the individual tools only get invoked if they are clicked on. So I only have one VI to execute for each tool. I do send the Platform Mods (shift, ctrl, etc.). That way the tool knows if it was Shift-clicked or right clicked, or just left clicked. I also use an array of pictures where the index in the array corresponds to an index in my tool array. So I load and verify the VIs in a directory, showing their icon in the picture array. Then I just need to track indices.

I am still unsure what all the different VIs for every Event are for. It seems sufficient to have one VI for each tool, but I haven't heard what you would have each Event-VI do.

David

[JDave]

QUOTE(Norm Kirchner @ Oct 19 2007, 05:51 AM)

Actulally the new LLB Viewer is written in pure G and has the possiblity of creating your own plugins. Just watch the NI week 07 videos and I'll give you the passwords to get into it. I would have to say that the code is 'Super Spiffy'

I looked into the code of the LLB Viewer, and what I could see looked 'Spiffy'. I think the 'Super Spiffy' code is locked.

Were you referring to the NIWeek 2007 Blog videos, or Keynote presentations, or ... ?

[Norm Kirchner]

It's the part of the blog video where you see [censored] over my mouth. I was just making a funny w/ regards to passwords :gathering:

[JDave]

QUOTE(Norm Kirchner @ Oct 25 2007, 07:04 AM)

It's the part of the blog video where you see [censored] over my mouth. I was just making a funny w/ regards to passwords :gathering:

I remember watching that video. I laughed at the time. Not laughing now...

You had my hopes up there, though I was wondering why you had a password to a NI VI. I do still appreciate you pointing me to that VI. It did hint at least at plugin capability. Which makes me wonder if there is a list someone has compiled of interesting unlocked VIs in vi.lib. I know there was a list of VIs in 7.0 that were unlocked and exposed scripting elements. But I know that I occasionally find a neat implementation from a VI in vi.lib. Even a list of really interesting locked VIs would be good.

But that is a bit of a tangent. My eye really caught on the plugin data containing three different VI references: Display, Build, and Select. This is similar to Ton's idea of having multiple VIs that run for different events. These VIs, based on their control and indicator names, seem to deal with Building menu items and subsequently Selecting those items. The Display VI is used for sorting filenames??

I had considered having a VI for each tool that output what 'Toolbar' capabilities it had. Did it have a Setup option, did it behave differently if selected with various PlatformMods (Shift,Ctrl,etc.)? But there may be other things to do here. What other functionalities might benefit from having separate VIs to execute them. @Ton - What were the functionalities to be in the VIs for the Mouse Enter / Move / Leave events?

David

[Ton Plomp]

QUOTE(JDave @ Oct 25 2007, 09:20 PM)

@Ton - What were the functionalities to be in the VIs for the Mouse Enter / Move / Leave events?

David

It was meant for hover effects and other stuff, it got me on the track for the Boolean XControl.

I was thinking what info could be of interested for a button.

Ton

[JDave]

QUOTE(tcplomp @ Oct 25 2007, 03:54 PM)

It was meant for hover effects and other stuff, it got me on the track for the Boolean XControl.

I was thinking what info could be of interested for a button.

Ton

Planning ahead. Very cool :thumbup:

[crelf]

QUOTE(Norm Kirchner @ Oct 26 2007, 12:04 AM)

It's the part of the blog video where you see [censored] over my mouth. I was just making a funny w/ regards to passwords :gathering:

I've created an advanced image processing function that filters out the [censored] part of the image - if anyone wants to know what Norm said, send me a blank cheque made out to "cash"...

[JDave]

I was looking at the new wiki page on plugins, and I got thinking about directory structures for plugins. How do people organize plugins? Do you have a separate directory for each plugin, all within a 'Plugins' directory. If so, how do you differentiate plugin VIs from support VIs? Connector Pane? Naming conventions?

If you use an llb file there is the option to specify a 'top-level VI'. This can independently distinguish which VIs should be loaded as plugins. But are llb files decreasing in usage? Is there another way to do this?

These are important questions since the Toolbar will depend completely upon some sort of plugin architecture. I am hoping for some feedback on questions like this. Norm made the point earlier that NI can look at our efforts and see what we want from a Dev Toolbar. So tell me what you want...

[crelf]

QUOTE(JDave @ Oct 31 2007, 04:31 AM)

...how do you differentiate plugin VIs from support VIs? Connector Pane? Naming conventions?

Yes and yes Using connector panes is a useful way to make sure that LabVIEW only opens appropriate VIs - when you open a reference to a VI using a static VI Server open, it will error if the connector pane of the VI is of the wrong type. Using naming conventions means it's easy for humans to differentiate between plugins and non-plugins. That said, I usually distribute plugins in their own folders and have the calling architecture traverse it's plugin directory and one level down - I just find uninstallation cleaner this way.

QUOTE(JDave @ Oct 31 2007, 04:31 AM)

If you use an llb file there is the option to specify a 'top-level VI'.

I'm firmly in the camp of "llbs should never be used". They are a relic of when OSes were limited to 8.3 naming conventions. They're difficult to control under SCC. If you want to encapsulate your code components in one file, use something like a zip file instead. At least if it's corrupted, there's more wide-spread usage, hence more support of getting to your files (but they're already in SCC, right? )

[JDave]

QUOTE(crelf @ Oct 30 2007, 07:31 PM)

Yes and yes Using connector panes is a useful way to make sure that LabVIEW only opens appropriate VIs - when you open a reference to a VI using a static VI Server open, it will error if the connector pane of the VI is of the wrong type. Using naming conventions means it's easy for humans to differentiate between plugins and non-plugins. That said, I usually distribute plugins in their own folders and have the calling architecture traverse it's plugin directory and one level down - I just find uninstallation cleaner this way.

This sounds good. It seems to be limited to plugins that run to completion, however. If the Toolbar were to call a tool that floats and waits for the user to close it, it would lock the Toolbar until it was done. Is this desirable, limiting to one tool running at a time? It might be.

I had considered checking the VI for controls with certain names instead of a certain connector pane. Then you would set the controls by name. This would allow for calling a VI with the Run method and choosing to NOT Wait Until Done.

QUOTE(crelf @ Oct 30 2007, 07:31 PM)

I'm firmly in the camp of "llbs should never be used". They are a relic of when OSes were limited to 8.3 naming conventions. They're difficult to control under SCC. If you want to encapsulate your code components in one file, use something like a zip file instead. At least if it's corrupted, there's more wide-spread usage, hence more support of getting to your files (but they're already in SCC, right?

)

Thanks for your thoughts on that. I thought I had heard similar sentiments, but I still see them quite a bit in the plugin tools that NI distributes. Does NI plan on using them long term?

[crelf]

QUOTE(JDave @ Nov 7 2007, 10:59 AM)

It seems to be limited to plugins that run to completion...

Well, you don't need to *run* the plug-in when you're checking its connector pane - you just need to open it.

QUOTE(JDave @ Nov 7 2007, 10:59 AM)

I had considered checking the VI for controls with certain names instead of a certain connector pane.

While absolutely a valid method (as long as all your developers stick to it ) you might as well just use the VI name.

QUOTE(JDave @ Nov 7 2007, 10:59 AM)

(llbs): Does NI plan on using them long term?

I *think* I remember hearing rumbles that they aren't looking at supporting them long-term, but you'd have to ask NI that

[Ton Plomp]

QUOTE(crelf @ Nov 7 2007, 02:32 AM)

I *think* I remember hearing rumbles that they aren't looking at supporting them long-term, but you'd have to ask NI that

Well I seem to remember an interview I read where a NI representative mainly said

QUOTE

NI doesn’t talk about future functionality

Ton

[crelf]

QUOTE(tcplomp @ Nov 7 2007, 05:04 PM)

Well I seem to remember an interview I read where a NI representative mainly said...

:thumbup: Well put!