JDave

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:

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

QUOTE(Yen @ Oct 18 2007, 11:48 AM) Maybe, but they won't be able to resist version 16 being LabVIEW XVI.

QUOTE(PJM_labview @ Oct 17 2007, 04:46 PM) 1) That makes things easier. Moving unconnected controls offscreen seems like an unfriendly step to have to take, but I don't like the extra step of needing to select only the controls I want either. 2) Combining these rules with also mimicking the connector pane is quite difficult. Like Mark said, you would want to use one or the other. Besides, would you really place the error clusters at the top of the FP if you were connecting them to the bottom terminals? Unless you can define ALL of your connections via naming/class rules, I think the FP needs to at least roughly mimic the connector pane layout. QUOTE(martin@aerodynamics @ Oct 18 2007, 05:07 AM) What I miss is someting like an Abort button to keep the old connetor pane... If you were referring to my tool, you can Undo it. After hitting done, just hit Ctrl-Z. Keeping the original connector pane if controls are wired is a different option that I haven't explored. QUOTE(mballa @ Oct 18 2007, 11:19 AM) ...this tool has saved me a lot of time what usually takes 3 minutes I can do in 20 seconds. I think the biggest benefit is that I create more subvis in my code. The fear of making a SubVI and then spending non value added time cleaning it up is greatly reduced. Mark, This tool seems more like an entire toolbar. :thumbup: I was already thinking about toolbars, and Ton's link to his http://forums.lavag.org/VI-activation-event-t3534.html' target="_blank">toolbar ideas reminded me that where it would be best to combine efforts is to work on a Development Time toolbar. Plugin tools and all. I mean this would be a perfect starting point of a Coding Challenge. Provide a toolbar framework and challenge people to come up with really neat tools to put in there. There was some brief mention of an OpenG toolbar, but nothing came of that. Anyway, I will make another thread to continue this discussion. To coalesce efforts on the arranging and wiring of controls to the connector pane, I have a thought. It is cumbersome to require controls to be placed in exact bins like my tool requires. It is also cumbersome to put in placeholder decorations like your tool requires. Are there any novel ideas on how to take some Front Panel with controls and make 'intelligent' terminal assignments? I think some arrangement is necessary as a building point. But what is an 'easy'? requirement for this arrangement to allow terminal assignments without requiring much extra work on the part of developers?

QUOTE(PJM_labview @ Oct 15 2007, 02:23 PM) I had a few ideas that might align with your workflow. But a few questions - How would you envision handling controls that you don't want connected? Would they be required to be made not visible, or would you restrict the wiring to selected controls, or would you have a special place to put controls you don't want connected? Do you envision your visible front panel area to mimic the connector pane, so the relative positions of the controls on the front panel are in roughly the same place as the terminals? David

QUOTE(tcplomp @ Oct 17 2007, 11:06 AM) I worked on mine for about three days, so I am not surprised. I will need to look at the updated version to get some more ideas :thumbup: . Maybe there is some good room to combine efforts. QUOTE(mballa @ Oct 17 2007, 11:12 AM) Where is the "VI activation event" located? It is under the <Application> option in the Event Sources box when you add an event to the event structure. Ton - I have not needed to register for any app ref. In LV8+ there is a field for the App Ref of the activated VI.

QUOTE(tcplomp @ Oct 17 2007, 04:37 AM) I like the showing the icon afterwards. Fitting the decorations to the current size can be problematic. What is the minimum allowable size? Spacing is already tight with clusters and arrays. I wish I could change the default panel size on new VIs to be a little bigger, actually. QUOTE(martin@aerodynamics @ Oct 17 2007, 06:38 AM) I think it's a very good tool! But what are you making, if your controls/ indicators are (verry) big clusters? Overlapping controls are not that nice... Verry good question. It is important to remember that the majority of controls are small enough. The majority of my very big clusters are made into Strict Typedefs and shrunk down to something more manageable. Clusters taking over my FP are not that nice either. For the remaining cases, I suppose I would use the tool to auto connect what I could and tweak the rest. David

QUOTE(mballa @ Oct 15 2007, 11:08 PM) I changed the file in this thread to fix the crashing. I also implemented the redrawing of the boxes if settings change. I wanted to get some more feedback on the idea of moving boxes around. How did you envision this? Any other ideas from other people on how to change this to work better with your own workflow? How do all of you typically go about wiring your subVI connector panes? David

QUOTE(crelf @ Oct 16 2007, 08:48 AM) I meant rusty as in involving scripting and not well proved. If I thought it would easily crash I would have stated so. But dabbling in scripting is asking for the occasional crash. Where is the place for things I need worked on? I was looking for feedback and ideas on how to improve the tool, and to see what people thought. But I certainly appreciate if someone found a serious bug that I need to fix. David

QUOTE(mballa @ Oct 15 2007, 11:08 PM) Hmmmm... That's not good at all. I did see some crashing when moving the box decorations, but it seemed to go away when I put a Defer Panel Updates in. I will take a longer look at that. I posted this in Rusty Nails because I felt it was still a little rusty, but I wanted some feedback on it. Thanks for finding this. QUOTE(mballa @ Oct 15 2007, 11:08 PM) I do have a few additional suggestions aside from fixing the crash. How about redrawing the decoration boxes when the scale or pattern is changed. Also it would be nice if we could move the boxes to the controls and have them auto wire. Redrawing the boxes would make it easier to see what changes would look like. Very nice suggestion. Moving the boxes is a very novel idea. Each box corresponds to a terminal, so one would have to keep the same general layout. If you dragged a box from the top to the bottom, it would still link to the top terminal. Otherwise you have to get into relative spacing. Or is this not what you were envisioning? P.S. I appreciated the inspiration I received from your SubVI Fixer that I mentioned to PJM. Thanks for posting your code for that. David

QUOTE(PJM_labview @ Oct 15 2007, 02:23 PM) I agree that minimizing work was very much my effort. The tool does attempt to connect all the controls at the beginning, but requires that they be within the grid boxes. Mark Balla wrote a http://forums.lavag.org/SubVi-Fixer-tool-t1597.html' target="_blank">really neat utility that does more of relative spacing like I think you are asking. This requires quite a bit more work than "Is the control in the box?". Personally, to make this tool work with my workflow, I have changed my default grid spacing on the front panel to 200. Then with a scaling factor of 25, and the 4x2x2x4 (4815) pattern, it is obvious where to place the controls and indicators while working. Then when I am ready to wire it all up, I run the tool. I also have it set up with a keyboard shortcut through a toolbar utility that I built. So I press the shortcut key and then I hit Enter (if no tweaking required). Done. To Michael : I will submit this to the Code Repository, and see what I need to clean up David

I posted a while back how I was feeling there must be a better way to wire up my controls to the connector pane on my subVIs. My experiments since then have been quite fruitful. Auto ConnectorPane Puts a huge scaled connector pane decoration on your front panel. Connects up any controls or indicators that are in the oversized terminal boxes. Drag your controls and indicators to the desired box, or outside the decoration to disconnect them. Works with all connector pane patterns. It's the best thing since dragging your mouse back and forth between the connector pane and each and every control and indicator! Just put the .llb file in your project folder in the LabVIEW directory. Restart LabVIEW and you will have an option in the Tools menu for Auto ConnectorPane. LV 8.2 or higher is required, and depends on several OpenG libraries (you should have OpenG installed anyway, of course). Auto ConnectorPane.llb Hope you enjoy.

QUOTE(robijn @ Oct 15 2007, 09:16 AM) I like that!! :thumbup:

QUOTE(Justin Goeres @ Oct 12 2007, 05:16 AM) I haven't done much in 8.5, but if the behavior is the same you just need to create 10 items (VIs, etc.) After that the numbering goes blank. Its sort of like a feature you have to unlock by writing lots of code. So just script the creation and deletion of 10 items, and then run that whenever you start coding.

QUOTE(Jim Kring @ Oct 3 2007, 01:00 PM) If only the Undo stack didn't get flushed every time you save... Is memory really that tight? Buy another few Gigs of RAM.

QUOTE(Michael_Aivaliotis @ Sep 28 2007, 03:39 PM) It is both a VI setting and an environment setting. The environment setting only works on newly created VIs. This wouldn't solve my problem, but it would be nice to have an additional dev. environment setting that specifies to ONLY use the environment spacing. This would only apply when opening VIs.

As I was coding today, it struck me that there should be an easier way to wire controls up to the connector pane. I remembered seeing something along those lines here on LAVA. Apparently the search is working better, because eventually I found mballa's SubVI Fixer Tool. My thought before I found this tool was to have a LARGE grid spacing (~200). Then one can easily place the controls and indicators into these 'bins'. It is simple to then assign the controls to connector pane terminals. The rest of the code is found in the Fixer tool. But as I searched through the property nodes and invoke nodes, I didn't see anything regarding the grid spacing. Does anyone know if there is a way to programmatically change the grid spacing? I thought about temporarily setting it to 200, then restoring the original settings. Thanks for any thoughts. David

QUOTE(shoneill @ Sep 21 2007, 12:49 AM) Too late !!! Congratulations!! Do enjoy the moments (that you do catch some sleep :laugh: )! David

QUOTE(Michael_Aivaliotis @ Sep 17 2007, 08:52 AM) Now just restart LabVIEW and see if the shortcut still works. :headbang:

QUOTE(David Boyd @ Sep 14 2007, 01:42 PM) Thanks, Dave. I should have put this in the scripting forum, apparently. Both those suggestions work great. Somehow I missed the Application Method. The 'New VI' primitive is still on the palette, at least the OpenG palette. I verified it still works in 8.2.1. As for the lack of menubar, I am creating a standalone toolbar. If all other VIs are shut down, the toolbar still stays up because it is a VI. I wanted the option to bring up a blank VI so the toolbar wouldn't be so lonely.

Does anyone know how to programmatically open a blank VI? The menubar will be hidden, so I can't use the menu shortcut. The hook VI lv_new_vi.vi doesn't exist to call. I didn't notice an Application invoke node method. But there must be some other way. (Probably as easy as Ctrl+N ). David

QUOTE(Eugen Graf @ Sep 13 2007, 11:57 AM) If these are 'industrial projects', wouldn't you expect to pay for support? The upfront money almost always means less cost in the long run.

QUOTE(David Boyd @ Sep 12 2007, 02:25 PM) Well, well... I'm not doing too hot here. You are right. I didn't even notice the lack of coercion dot. Thanks for correcting this, and pointing out some new behavior for enums that I didn't know about. I do agree with jpdrolet, though, that it would be better documented in the code to put the correct enum constant down, rather than incrementing or decrementing.QUOTE(orko @ Sep 12 2007, 01:42 PM) Type cast works as well.I knew something was bothering me about this. It works since, as Dave pointed out, it is really just casting an enum to the same enum. But I had tried to typecast a numeric to an enum before and it doesn't work. There is no error, and it compiles. But for some reason the enum output always goes to the default value (the first element).

QUOTE(jpdrolet @ Sep 12 2007, 01:17 PM) That is a really good point. I really need to look past just answering the question more often...

QUOTE(EJW @ Sep 12 2007, 12:59 PM) It may be that you have the VI set to 'Show When Run' or something like that. Using the 'Run VI' method ignores this setting, so you have to explicitly open the front panel from within the second VI. I will get a little code example together. David