LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Match Regular Expression not allowed with inlining, why?

Anyone knows why the "Match Regular Expression" primitive is not allowed in a VI on which you enable inlining?

 

match regular expressionmatch regular expression


We have two ears and one mouth so that we can listen twice as much as we speak.

Epictetus

Antoine Chalons

Message 1 of 11
(2,638 Views)

Hi Antoine,

 

MatchRegEx uses the (3rd party) PCRE library as written in the LabVIEW help.

 

I guess that's the reason why it is not allowed for inlining: is that library thread-safe, does it allow for reentrancy, other possible reasons?

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
Message 2 of 11
(2,624 Views)

I see is no reason for this.

 

The XNode contains nothing that can't run in an inlined VI. You can literally copy paste the generated XNode code in an inlined VI, and it works.

 

The DLL is thread save, and doesn't run in user thread. Even if it did, it would run in an inlined VI.

 

I use a reg.ex. as a subVI all the time. This VI is based on the XNode, but isn't an XNode. It returns the outpus as an array. This was the reason to make it, an array is often more convenient than a resizable function.

 

In it, I put a note to myself:

NOTE: The dll uses string handles. This will sometimes result in unexpected results (empty strings\crashes) when this VI is run without caller.

 

Not sure if the string handles are the cause of this, but it was funky.

 

The XNode has the same interface, and inlining it in a VI basically makes it run without a caller when the inlined VI is run. Perhaps that is why they marked the function as unsafe for inlining?

 

Anyway, feel free to use the VI. It's on Github:

https://github.com/Carya-Automatisering/Configuration-File-Library/tree/master/Carya%20Config/SubVIs

 

You might want to set it to run reentrant. That makes sense. Not sure why I didn't. It might crash. 

Message 3 of 11
(2,601 Views)

9: 1 vi2InlinableDiagram: Typeprop says this VI's diagram is safe to Inline (used to be vi2ObjIDChgOK)

The flag says it's save to inline... Not sure why it isn't possible.

Message 4 of 11
(2,596 Views)

I ran across this today... interestingly enough, you CAN use "Search and Replace String" with "Regular Expression" mode on. It appears to use the same library.

0 Kudos
Message 5 of 11
(2,181 Views)

@BertMcMahan wrote:

I ran across this today... interestingly enough, you CAN use "Search and Replace String" with "Regular Expression" mode on. It appears to use the same library.


I'm sure there's no need for this restriction... Just like expression nodes and property nodes and invoke nodes.

 

I often use a VI that uses the same dll (plug), but it returns an array of results. This can be more convenient sometimes. This VI does work in a .vim.

0 Kudos
Message 6 of 11
(2,143 Views)

wiebe@CARYA wrote:

@BertMcMahan wrote:

I ran across this today... interestingly enough, you CAN use "Search and Replace String" with "Regular Expression" mode on. It appears to use the same library.


I'm sure there's no need for this restriction... Just like expression nodes and property nodes and invoke nodes.

 

I often use a VI that uses the same dll (plug), but it returns an array of results. This can be more convenient sometimes. This VI does work in a .vim.


Allowing property nodes and invoke nodes in inlined VIs would would create a big hole in the already-weak password protection for block diagrams.

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 7 of 11
(2,117 Views)

Forgive the off topic request but Paul could you expound on why that is?

0 Kudos
Message 8 of 11
(2,105 Views)

@BertMcMahan wrote:

Forgive the off topic request but Paul could you expound on why that is?


I'm drawing blanks here too...

0 Kudos
Message 9 of 11
(2,088 Views)

@BertMcMahan wrote:

Forgive the off topic request but Paul could you expound on why that is?


The LV password protection is a lock, not an encryption.  You can't get to a PW protected BD because the IDE respects the lock and won't let you in.  But a VI always has access to its own BD, even if it's PW protected (essentially that VI is inside the secured area).  When you inline a VI, that VI's code becomes part of the owning VI's BD.  If property & invoke nodes were allowed, then an inlined VI could access the owner's BD, even if it were PW protected.  Thus to break into a BD, you would only have to find a VI that's called by it, temporarily replace that VI on disk with a like-named inlined VI that opens the BD, then run the protected VI and voila, the BD opens.

"If you weren't supposed to push it, it wouldn't be a button."
Message 10 of 11
(2,069 Views)