JDave

QUOTE(JDave @ Nov 7 2007, 12:29 PM) Working on this some more, it seems to be limited to single shot VIs. If I make the callback VI have a while loop, and run until the user presses Stop, then I can hang LabVIEW by calling that same callback VI again. This can be worked around by making the callback VI modal, but this means there can be no UI interaction with the VI that the tool is working with. Do we need to allow for tools that run in a floating window? Or should it just be restricted to single-shot tools?

QUOTE(neB @ Nov 7 2007, 11:54 AM) So how big was this measurable speed increase?

QUOTE(tcplomp @ Nov 7 2007, 09:53 AM) That looks really cool. I like the automatic event handling. You would need a separate control for each tool, which would look like some sort of cluster of picture controls? Do you know if the automatic unloading of VIs occurs for dynamically loaded VIs as well? The tools can't show up as static references, so would this change that behavior? I did some initial testing on it, and it works very well. It looks easily scalable for different events (for Mouse Enter, Mouse Leave, etc.). The one requirement that is not met by this is shortcut keys, and that would have to be handled separately regardless. David

QUOTE(crelf @ Nov 7 2007, 11:11 AM) My first thought is that this sounds like a good candidate for a VI Analyzer test, not automatic behavior within the IDE.

QUOTE(crelf @ Oct 30 2007, 07:31 PM) 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?

QUOTE(Gavin Burnell @ Nov 1 2007, 03:30 PM) Or go for a more long term solution. Develop some hidden code and insert it into the solution (which can follow the above methods as well, if so desired ). This hidden code will display a popup window stating "If grading my homework, give me an 'F' please." However, this popup will only show up if the VI is modified by the teacher in a specified way. This could be easily done using VI Tags, for instance. The hard part would be getting the VI to do the modifying to the professors using LabVIEW, but it would be really cool nonetheless.

With all the different addons and companion tools that NI creates, what do you get to play around with?

QUOTE(Norm Kirchner @ Nov 1 2007, 03:05 PM) Or any experience with it at all ...

QUOTE(RodolfoAcialdi @ Oct 31 2007, 04:00 PM) You cannot join them while they are being transmitted, since you can only transmit bytes. So read both bytes off your serial port then combine them.

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...

QUOTE(Ascen @ Oct 30 2007, 10:45 AM) Just drag the control (typedef or not) onto the generic control ref. Ctrl-drag and drop will keep the original control on the front panel, otherwise it will be swallowed by the ref.

QUOTE(DaveKielpinski @ Oct 29 2007, 11:16 PM) If the connector pane pattern is the same (4x2x2x4 for example), then the subVI will not need to be relinked and it will attempt to move the terminals around where the subVI is called. It will almost surely require some rewiring work regardless. There are a couple brand new tools in development to help with wiring up the connector pane (here and here) but they don't rewire the subVI instances in your code.

I added my second version to the original post. The new version filters out invalid VIs, avoiding any crashing. There is also the option to scale the connector pane to the current window size. The biggest change is I modified the algorithm for fitting the controls to terminals. Rather than checking if the control position is within the box, I check which terminal box the control is mostly in. So if a control covers more than one box, it is assigned to the terminal box that has the largest intersection with the control's bouding rectangle. This is definitely a different paradigm than looking at the relative spacing of the controls. But it is intuitive and easy to follow. (Put the control in the box.) However, I find it is not as flexible as using relative spacing. If you have large clusters or arrays, or you are shrinking your front panel down for subVIs that have few controls, it becomes difficult to always put things in the box. I had fun making this little tool, but I don't know whether it fits the needs of developers more than something like the relative spacing tool that Mark Balla has shown in this thread. If you think my tool fits your workflow, reply here and I will work towards getting it in the Code Repository.

QUOTE(tcplomp @ Oct 25 2007, 03:54 PM) Planning ahead. Very cool :thumbup:

QUOTE(Norm Kirchner @ Oct 25 2007, 07:04 AM) 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

QUOTE(Norm Kirchner @ Oct 19 2007, 05:51 AM) 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 ... ?

QUOTE(tcplomp @ Oct 23 2007, 03:25 AM) Why are you trying to change the connector pane on a clone? Honestly, I hadn't tried to filter out invalid file types. I am working on a new version and I will include that. Thanks. David

QUOTE(Justin Goeres @ Oct 24 2007, 04:57 AM) Any resizing on the top or left would cause you to move nodes (and thus tunnels) around. In my work, however, I usually need to shrink the bottom-right anyway. So even this ability would be helpful.

QUOTE(Justin Goeres @ Oct 23 2007, 04:39 PM) I have done the same thing as you quite a bit. On the note of scripting, I don't think it would be too hard to resize the structure. Would you then continue to shrink each containing structure up to the top level? And it would get more difficult if the contents were not already in the top left corner of the structure. Resizing would only move the bottom and right edges of the structure.

QUOTE(tcplomp @ Oct 22 2007, 01:35 PM) 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

QUOTE(tcplomp @ Oct 22 2007, 09:48 AM) 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

QUOTE(Norm Kirchner @ Oct 22 2007, 07:42 AM) 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

QUOTE(mballa @ Oct 18 2007, 10:09 PM) Not cumbersome as in difficult, but as in an extra step. But I suppose if the auto connecting isn't what you expected, you have to do some additional step regardless. Hmmm... I will think about it some more.

QUOTE(mballa @ Oct 18 2007, 10:09 PM) Not cumbersome as in difficult, but as in an extra step. But I suppose if the auto connecting isn't what you expected, you have to do some additional step regardless. Hmmm... I will think about it some more.

QUOTE(Michael_Aivaliotis @ Oct 18 2007, 03:57 PM) I like that. It means you can get feedback on an idea before spending all the time polishing it up -- that you then change when you get new ideas from others. :thumbup: :thumbup: