Jump to content

Class Method Browser


Recommended Posts

This tool is nice and will become very useful once the bug is fixed.

 

I tried your code and instantly experienced the bug. However there is a workaround:
Running the main VI directly from disk will prevent the crash.

 

Sadly it will crash the moment you close the UI. :frusty:

 

I found one issue so far (seem to solve the problem for me):
You store references to each library into a variant attribute that is collected in the Variant 'Reference Lookup List'.
>> Remove all dependencies to that list and fetch the references again in your 'Callable Methods.vi'.

In my case the Browser did not crash anymore... :lol:

 

post-17453-0-71250500-1376739502_thumb.p

 

However that does not fix the issue with calling the Browser from the Tools menu...

I don't know for sure, but it seems that the instance from the Tools menu compared to starting a
VI directly from disk is somehow different...?

 

Does anybody know more about that?

 

EDIT: Tested in LabVIEW 2013 (32-bit) on Win7 x64

Edited by LogMAN
Link to comment

I thought of a quickdrop tool at first as well. The problem with that is you'd have to select the wire, the do a ctrl+space. This would bring up a generic quickdrop. Now you'd need to do what? If you start typing, it just does default quickdrop search. It's not possible (as far as I know) to use a plugin to change what is searched. So maybe instead of typing you hit a quickddrop shortcut. Ok, now we have a list of methods, how do I display them? Can you just populate the quickdrop combobox? I could never figure out a happy way to make the plugin work, so i ditched quickdrop all together.

Link to comment
So maybe instead of typing you hit a quickddrop shortcut. Ok, now we have a list of methods, how do I display them? Can you just populate the quickdrop combobox? I could never figure out a happy way to make the plugin work, so i ditched quickdrop all together.

I'm no quick drop expert but this is how I'd do it.  Say CTRL+Space then CTRL+C (maybe that is semi-reserved) this brings up a new dialog window that shows the options, and you pick the one you want which then adds the code to the block diagram.  Closing this window does nothing, and calling another CTRL+C brings this window back to the front with new settings if it was never closed before.  Not ideal no but I think it could be used this way.

Link to comment
This tool is nice and will become very useful once the bug is fixed.

 

I tried your code and instantly experienced the bug. However there is a workaround:

Running the main VI directly from disk will prevent the crash.

 

Sadly it will crash the moment you close the UI. :frusty:

 

I found one issue so far (seem to solve the problem for me):

You store references to each library into a variant attribute that is collected in the Variant 'Reference Lookup List'.

>> Remove all dependencies to that list and fetch the references again in your 'Callable Methods.vi'.

In my case the Browser did not crash anymore... :lol:

 

attachicon.gifCallable Methods.vi.png

 

However that does not fix the issue with calling the Browser from the Tools menu...

I don't know for sure, but it seems that the instance from the Tools menu compared to starting a

VI directly from disk is somehow different...?

 

Does anybody know more about that?

 

EDIT: Tested in LabVIEW 2013 (32-bit) on Win7 x64

 I took a look into this. I noticed the crash when running in the tools menu. I didn't test the non-tools menu version because, well... It's slow now. There is a noticeable delay when clicking a wire. I NEED SPEED!!  :P

I'm no quick drop expert but this is how I'd do it.  Say CTRL+Space then CTRL+C (maybe that is semi-reserved) this brings up a new dialog window that shows the options, and you pick the one you want which then adds the code to the block diagram.  Closing this window does nothing, and calling another CTRL+C brings this window back to the front with new settings if it was never closed before.  Not ideal no but I think it could be used this way.

Yeah, this is similar to what I was describing. The problem is then the QD is basically just a separate way to launch the same tool (vs the tools menu). Which i could add, but it's still not a QD only solution.

QD feels like a "Every problem is a nail...." situation to me.

Link to comment
Yeah, this is similar to what I was describing. The problem is then the QD is basically just a separate way to launch the same tool (vs the tools menu). Which i could add, but it's still not a QD only solution.

QD feels like a "Every problem is a nail...." situation to me.

I agree.  I have found myself developing a tools menu item, and then changing it to a quick drop item instead.  When developing I find two shortcut combos is faster then navigating the tools menu.  Especially on a system where the items and order of the things in the tools menu potentially changes after installing something from VIPM.

Link to comment
QD feels like a "Every problem is a nail...." situation to me.

 

I completely agree. Don't get me wrong, I love QD, but I don't care for the collection of arcane keystrokes that are used to bend it to one's will. Ideally what I'd like is not so much to have a floating window open at all times, but a tool like yours come up due to some context like quick-drop does.

Link to comment
I completely agree. Don't get me wrong, I love QD, but I don't care for the collection of arcane keystrokes that are used to bend it to one's will. Ideally what I'd like is not so much to have a floating window open at all times, but a tool like yours come up due to some context like quick-drop does.

I like the context specific idea. Like some sort of pop up when you click a class wire. Wouldn't be that hard of a modification since I've got all of the logic. It may be a bit of a challenge to keep it on the useful side of things and not slide into the annoying side.

  • Like 1
Link to comment
I completely agree. Don't get me wrong, I love QD, but I don't care for the collection of arcane keystrokes that are used to bend it to one's will. Ideally what I'd like is not so much to have a floating window open at all times, but a tool like yours come up due to some context like quick-drop does.

 

I don't use quickdrop but I've always wanted a palette that shows (say 10 of) the "most used" VIs similar to how chrome shows the most visited web pages. I've also wanted dockable palettes so that the "favourites" could be docked to the top of the screen. I think it's very limited use of the screen space to have the floating windows (urrgghhh. The probe window!). The same could be applied to "quickdrop". Just dock it to the top of the screen and have a single text entry like the chrome address bar that drops down when you type stuff into it and goes away when it loses focus.

Edited by ShaunR
Link to comment
I don't use quickdrop but I've always wanted a palette that shows (say 10 of) the "most used" VIs similar to how chrome shows the most visited web pages.
There is something on NI.com/labs that claims to do the most visited palette, not tried it yet but might be worth a look.
  • Like 1
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.