DemoPad.com

Is it possible to use Dynamic Labels in Commands in the same way that you can for Numbers - i.e using [] brackets around the variable label name in the Command? If not, can this be added?

I'm trying to integrate a component that sends handles for data values back on events occurring - these handles can be identified using 2-way feedback, but I then need to be able to send these handles back to the component via a separate command to then identify the relevant track, etc data associated with the handle. It would be pretty trivial if I could use Dynamic Labels in commands in the same way I know we can use Numbers...

Thanks
Simon

Yes - just use square brackets, as with number variables, eg

Power=[MYLABEL]

where MYLABEL is the name of a label, maybe set to "ON" or "OFF" text in this case.

How would that work if you have a label and number with the same name?

You can use { } for number variables and [ ] for labels, but to be honest for the sake of simplicity it is probably better to call all your variables unique names so that you know what a variable is from the name, and in that case [ ] will work for both.

Yes, now that I know labels can be used in this way I will do that. Perhaps even a prefix would be better.

Thanks for the reply to my original query. Mostly user error on my part; I've successfully defined a Dynamic Label with a valid handle for my system and then successfully passed that back to the system using the [] syntax to do a valid call of meta-data.

What I can't work out is when I pull the handle from the 2-way feedback using a Regex expression, I get the correct handle returned into my Dynamic Label... but it has a trailing Carriage Return. I can see this by setting a test Dynamic Label and passing repeated concatenations of my taget Dynamic Label back to my Demopad (test) screen. Instead of 1 long line of text I get CRs after each concatenation. The extra CR is stuffing my attempt to automatically use the 2-way feedback to call the meta-data. I've tried tweaking various combinations of Regex coding in my 2-way feedback and also different Response Terminators for the 2-way feedback set-up. Nothing seems to work. What is especially frustrating is that the handle I need to extract is in the middle of the feedback from my device - if I set another Label to hold and display the full feedback string ie (.*) then I see no CR after the handle I'm pulling (albeit the full string also loads to the Label with a CR).

It must be something I'm doing in the process of loading the 2-way feedback to the Dynamic Label that is adding the trailing CR... but I can't work out what. Any ideas/suggestions very gratefully received.

Simon

Have you tested the string at this site? http://www.regextester.com/
Another good site for expression syntax: http://www.regextester.com/jssyntax.html

\r matches a carriage return

W.

Yes - I've tested at regextester.com; string tests OK with no carriage return identifed.

As I say, the odd thing is that if I match the full feedback string using just (.*) & map this to a Dynamic Label, there is no CR after the handle I actually want to identify (which is in the middle of the feedback string). It's as if whether I match just a part of the feedback (the handle in the middle) or the whole string, that the exercise of identifying the feedback & mapping it to a Dynamic Label adds a CR to the end of the value held by the Dynamic Label.

Not sure if anyone is seeing this behaviour? It may not mess up other use cases in the way my plan to load the feedback text into a call to a data identifying function does (as if the syntax for this call is off, it just throws an error).

Easy to test - just set-up a Label for testing & then once you have grabbed your text feedback & mapped it to a feedback Label, then set up a Page Load action to concatenate the feedback Label x2 & place this result in the testing Label - & have a textbox set to display the testing Label permanently. This will immediately show whether the feedback Label is holding a CR at the end...

Simon

I can confirm its happening here with label variables, it doesn't happen with number variables though. I'd send an email to suppot for a possible work around.

W.

Sometimes these problems are caused by not specifying the response terminator correctly - eg having it as \x0D when really it should be \x0D\x0A etc. Or forgetting that when you create a command using a label, the default command suffix is always added to the end of that command (though if you are using a test label on the GUI this wouldn't be the case).

Please compile a simple test project to demonstrate the issue & send to [email protected]

This has been confirmed as a bug, fixed for the next version of the app. For now, labels which have their content populated via regular expressions will have an extra carriage return at the end - making them unsuitable for use in dynamically generated commands.

Version 1.4.2 of the app remedies the situation.