JackDunaway

No. Just as Dynamic Dispatch has 'Must Override' and 'Must Call Parent', a static method could specify 'Must Implement' and 'Must Call Parent'. Note that 'Must Call Parent' has essentially the same semantics for Static and Dynamic Dispatch. Yet 'Must Implement' might be loosely analogous to a less-stringent 'Must Override'. Sorry for muddying the waters between 'Must Implement' and 'Must Call Parent' -- i see these going hand in hand in the context of, e.g., the LapDog.Messaging ctors.

Yeah; that's the motivation for shipping the parent with a unit test and a well-intended admonition. :-) For now, this seems like the best solution.

Could you push the mask down the stack from the UI layer down into the logic layer? Like, before writing to "masked sensor data" colorbox array indicator, replace masked values in a for loop? Or are there specific reasons to keep the mask at the UI layer?

Nope; nowhere near what i was originally looking for. The opposite, rather. Static methods, called by an application that statically constructs a child class. It's all very static on purpose -- no dynamic run-time decisions, because the problem domain does not call for dynamic or double dispatching or dependency injection or any other flavor of dynamic run-time ability. Taking this into the LapDog.Messaging domain: Consider a process that needs to send a string to another process; it's going to construct the message using LapDog.Messaging.v2.NativeTypes.lvlib:StringMessage.lvclass:Create StringMessage.vi. This problem domain would never require run-time selection of another ctor, whether through dynamic dispatch, double dispatch, etc. -- because the caller needs to send a string. Now, taking a look at all of the message ctors in LapDog.Messaging.v2.NativeTypes.lvlib, they all call RenameMessage.vi. -- yet I would suggest it's better if they called Message.lvclass:Create Message.vi, their "prototype", the ctor that exists in the parent -- bear with me; this is not a criticism, it's what I see as a great candidate for "Must Implement": For a moment, consider the calling of this particular function essential to the construction of a Message object for it to be viable within the framework. Further, even though this is just one function, consider it representative of "the collection of all the essential functions" that must be called in the construction of a Message object. (One very real upgrade we might want to perform in this case is timestamping the message, and we would not want to go into each of the concrete implementations to ensure they call Apply Timestamp.vi) What I'm suggesting is that each of the concrete Message ctors calls Message.lvclass:Create Message.vi instead of calling Message.lvclass:RenameMessage.vi. With this strategy, we allow the parent to templatize the sequence of essential constructor functions. If Message.lvclass were able to specify 'Must Implement' and 'Must Call Parent Implementation', we formalize the definition of Create StringMessage.vi as implementing -- which is discretely different but having traits in common with overriding -- the functionality of the parent class method Create Message.vi. Further, we guarantee the parent method called in order to perform the essential tasks that construct a well-formed message object. And we get the unique ConPanes we desire in the concrete implementing method. I've mentioned previously (post #13), and AQ brought up again (post #132: It may not be proper to even specify the function name (i.e. one might have "Write Boolean.vi" and another have "Write Double.vi")), that this "Must Implement" feature is gated by an inheritance relationship defined through a GUID private to the class rather than filenaming conventions of the method; this is evidenced with the desire for StringMessage.lvclass:Create StringMessage.vi to implement Message.lvclass:Create Message.vi yet not have its same filename. With these features and contracts in place, if a developer decides to subclass LapDog.Messaging.v2.lvlib:Message.lvclass by creating myArbitraryStructureMessage.lvclass, we can be guaranteed that it both implements and calls the parent implementation of the essential ctor Message.lvclass:Create Message.vi, yet is able to give it any name deemed fit with any conpane necessary to construct the specific object. The prime motivation here is inverting inversion of control; would one call this taking control? It's an exercise acknowledging that statically composed applications, when the problem domain allows, is superior to dynamically composed systems, in terms of ease of development and troubleshooting and maintenance. I think it would be handy to have language features such as 'Must Implement' that acknowledge the merits of subclassing without necessarily leveraging dynamic run-time abilities. Thoughts?

Gotcha. Yeah, that's a potential code smell -- stringly-typed rather than strongly-typed prototypes. Now, your ctors and methods are subject to run-time errors.

Will you elaborate?

Hey Mike, this weekend project i worked on a while ago may give you some ideas -- https://bitly.com/CognoscentUI

Choices, choices.... Dash (http://drivewithdash.com/) -- led by a familiar face who's no stranger to LabVIEW!

The only thing that jumps out is it looks like you're using LV2010 -- hopefully this issue would not bite you in later versions. Otherwise, it feels like a bug.

Can you post a sanitized version of the LVLIB XML?

The most real challenge has been simply interrupted cognition and lost time waiting for things to happen -- connections over RDP are oftentimes klunky -- it feels like I'm always switching between engineering and devops mindsets, and this thread swapping is inefficient -- these are purely anecdotal issues, YMMV. My best advice is to jump right in with what you're trying to do, and post specific issues as you run into them. (Also, it sounds like you're making the good choice to develop locally, then deploy the executable remotely. After walking down the path of attempting to develop remotely, this was far too burdensome due to the latency of RDP -- I could never get into 'the groove')

Replace your format specifier with the one linked by Philip Brooks for ISO-8601 and XKCD compliance. http://xkcd.com/1179/

The problem domain of deploying to and developing on a remote Server instance has challenges and nuances not present on desktops and local VMs; yet I have not run into inherent problems or incompatibilities between LabVIEW and Windows Server 2012 (or 2008, when i used that). Are you concerned about something in particular?

Well, it depends. At what speed were you, the observer, traveling with respect to the execution speed of the block diagram?

Well, it's kinda not a new string... it's just a noncontiguous substring. (Can a substring be defined as 'noncontiguous'? Perhaps, no, and what i desire is impossible.) Wow, thanks for going out of your way to recreate! Sorry snippets broke for you That is basically the way I'm solving the problem right now; with extra syntax. The prime motivation for finding a *purely* regex solution is to generalize this problem -- consider wanting to remove adjectives from both nouns: The fox jumped over the dog This general solution more closely matches my problem domain. (This thread presents the simplest form of the problem, since I can't even figure that out; or if the desired solution is even possible!)

That got me excited... but it's not quite right. The whole match is still just the submatch, because the lookarounds are zero-width. Virtual +50 bounty for the regex that makes the green light come on in the following test harness:

It would be helpful to have access to the text that was replaced. It is easy enough to create a re-use VI that does this; I'm just curious if the ability already exists.

Well, simply finding a submatch is the easy part ;-) What I'm really interested in doing is returning the original input string as the match, minus the submatch. Figure this out, and then we can fly around on vines saving days :-)

OK; so, the consensus is that there does not exist a single regex to solve this? (I was really hoping to learn of a solution that could be achieved purely by the regex engine.) The best name I can come up with for what I'm trying to do is submatch extraction, where the whole match depends on matching directives before and after the submatch, yet excludes the submatch like this:

How can I exclude a variable-width, inner part from a regex match? For instance, given the three following inputs: The quick brown fox jumped over the lazy dog The quick brown fox jumped over the sleepy dog The quick brown fox jumped over the hotdog I want to match the following: The quick brown fox jumped over the dog I have investigated negative lookarounds, but since these are zero-width assertions, I can't easily figure out how to include additional regex directives on *both sides* of the lookaround. Is this problem relegated to the use of Search and Replace String configured for regex matching, or can this be achieved with a simple regex match? Here's a screenshot of one of my naïve attempts using RegexPal; a successful attempt would also show "dog" highlighted as part of the match, but excluding the dog modifier. At least it doesn't match 'frog' :-)