Jump to content

Labels on shiftregisters


Recommended Posts

Hi guys,

I have the habit of always labeling my shiftregs on the left hand side of the loop they're on. I use free labels for that, but it would be nice if the labels where (optionaly) automatically created (like with objects on the FP). They would be attached to the shiftreg, moving with it when the shiftreg is moved up or down.

besides being a handy feature for myself, it would probably also encourage others who don't label their shiftregs now to do it anyway, because it would be the next logical (more or less forced) step after creating the register.

What do you guys think?

Link to comment

QUOTE(Yen @ Nov 8 2007, 05:41 PM)

Yes of course.. But for simple (lv2-style) sub-vi's where you know not much will change later on, it's still convenient to just use a shift reg or two-three..

I'll enter it in the product suggestion center...

Link to comment

QUOTE(Jeffrey Habets @ Nov 8 2007, 12:55 PM)

Hi guys,

I have the habit of always labeling my shiftregs on the left hand side of the loop they're on. I use free labels for that, but it would be nice if the labels where (optionaly) automatically created (like with objects on the FP). They would be attached to the shiftreg, moving with it when the shiftreg is moved up or down.

besides being a handy feature for myself, it would probably also encourage others who don't label their shiftregs now to do it anyway, because it would be the next logical (more or less forced) step after creating the register.

What do you guys think?

Yup, sounds like good idea with solid reasoning.

I look forward to this in future versions......

Thanks

Shane.

Link to comment

QUOTE(Jeffrey Habets @ Nov 8 2007, 04:55 AM)

Hi guys,

I have the habit of always labeling my shiftregs on the left hand side of the loop they're on. I use free labels for that, but it would be nice if the labels where (optionaly) automatically created (like with objects on the FP). They would be attached to the shiftreg, moving with it when the shiftreg is moved up or down.

besides being a handy feature for myself, it would probably also encourage others who don't label their shiftregs now to do it anyway, because it would be the next logical (more or less forced) step after creating the register.

What do you guys think?

I think it's a great idea. I used to put it in the suggestion box about every version, but lately it slipped off my radar. I would also suggest built-in lables for Sequence-Locals. (Not that I would ever use a Sequence Local!) It seems obvious to me. NI pushes for programming standards, including good documentation, but this obvious feature remains missing.

Cheers,

Dave T.

Link to comment

Hi

Today i have creat a small tool that can perhapse help you . This tool place a name in description attribut for wire that you before select on diagram.

First step:

Please place the "Give name to wire.vi" in your labview\project folder and restart labview.

Second step

Open Vi and select one Wire and make Tools\Give name to wire.vi

If all is correct, this Vi promt you for give name to this wire.

Last step

Place mouse in wire and show it name in contextual help.

Nota : have use CCT_Get User App Reference__CCT.vi part of the Code Capture Tool and is covered by the BSD license (see code reposary of lavag)

Eric

Link to comment

QUOTE(BOBILLIER @ Nov 14 2007, 01:09 AM)

Open Vi and select one Wire and make Tools\Give name to wire.vi

If all is correct, this Vi promt you for give name to this wire.

Last step

Place mouse in wire and show it name in contextual help.

Nota : have use CCT_Get User App Reference__CCT.vi part of the Code Capture Tool and is covered by the BSD license (see code reposary of lavag)

Eric

One question, how is this faster than right click->description?

Ton

(good to see you use the CCT :thumbup: )

Link to comment
  • 2 months later...

QUOTE(gosor @ Jan 31 2008, 03:53 PM)

I agree, it would be usefull to add a comparable feature for local variables of stacked sequence .

I don't agree with this latest addition.

There are virtually no reasons to use any stacked sequences in a well-designed LV application.

There are even fewer reasons to use sequence locals.

I don't think NI should invest any extra development time in a feature that only supports bad programming style.

Sorry for the harsh words, but I had to go through my share of stacked-sequence-applications, and I didn't find one stacked sequence which could not have been replaced using other features, like sub-VIs. In all cases, this would have improved readability of the code a lot!

Link to comment

QUOTE(silmaril @ Jan 31 2008, 11:56 AM)

There are virtually no reasons to use any stacked sequences in a well-designed LV application.

This is an arguement that we've had before, so let me cut to the chase: There are few reasons to use any stacked sequences in a well-designed LV application. Like all rules, there are exceptions. There are cases where you need to force dataflow where it doesn't currently exist, and encapsulating code in a subVI or a flat sequence structure can be equally appropriate. Like all programming paradigms, it's all about using the right tool for the job.

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.