PDA Seach and Replace String Primitive Bug

[rberger]

I'm using LV PocketPC 8.0.1.  The Search and Replace String primitive in the String palette does not work correctly.  When you use set the Replace All input to true, the results are not correct.  Try it.  The solution is to use the attached VI - Search and Replace String - General.

[Jarrod_S.]

Thanks for this information. I'm glad you devised a workaround to this situation. I tried to reproduce it, but unfortunately I only have 8.0 installed. The Search Replace function seems to work fine in 8.0 with Replace All set to true. As soon as I can get my hands on an 8.0.1 machine I'll try it again.

Did it always give incorrect data? Is there any other information you can give about the situation you called the function in? Was it called in a loop, or does it fail regardless?

[rberger]

Hi Jarrod:

More info for you.  Looks like the following occurs in v7.1 and 8.0 also.  If one provides a replacement string and sets replace all to true, the primitive gives incorrect output if there was no replacement made.  In other words, the output string should be the same as the original input string.  The following source code works as expected on the desktop but gives an empty output string on the PDA.  I built a PDA executable in 8.0.1 for you to try.

Robert

[rberger]

Sorry, wrong file.  Try this attachment

[Jarrod_S.]

Hi Robert,

This is very strange. I was able to reproduce the issue you have been seeing with the VI you attached. It works fine on the development system, but when targeted to PocketPC emulator, it outputs an empty string.

The strange thing is that I can't reproduce this from scratch. I created a VI that was virtually identical to your, but it failed to cause this problem. I then did some testing to see if this was restricted to the case where the inputs were constants, or whether the Replace string needed to be unwired. I changed your code to have a control for the input string and then re-ran the code. This time it worked fine. It output the exact same string as the input. So I changed the string control back to a constant to try to reproduce the original behavior, and it worked fine this time!

So I'm still having trouble reproducing this, I must admit. If I can't find out exactly what causes this, I can still pass your VI and built executable on to R&D for further investigation. If you run my VI attached below, do you see the correct output? It should be very similar to yours, but it works fine on my system (PDA & development).

[Greycat]

I have found another strange happening with the Search and Replace VI under PDA... in the following example ... the Search and Replace VI seems to affect the string even though it is not wired to it  ... this is a very odd issue ... where it will remove the character but repeat the last character in the string ... all this while it is not wired to it ...

in the example ... enter characters in String 1 but make sure you put two words in it seperated by a space and press ok ...  observe string 2.  Incorrect but not really that strange ... until you look at the diagram .. the input to string 2 indicator is not even wired to it ... it is wired directly to the original in string 1 .. now this is strange ...

I decided to add to this thread instead of starting a new one as these seem to be somewhat related ... any thoughts or responses are appreciated ..

Greycat

[rberger]

Sorry its taken me so long to respond.  I've compiled and loaded it into my Windows Mobile 5.0 smartphone. 

Yes, you are right and now you have four eyes saying this is a strange bug.  The Seach String and Replace primitive for the PocketPC PDA does some really really strange things.  I still use the workaround because some of my apps were inconsistent.  After using the workaround VI, my apps ran fine.  Hope the folks at NI looks into this primitive because it has intermittent bugs!

Have a nice day.

Robert

[Greycat]

Thanks for checking this out ... I appreciate it..

Here is a bump to see if we can get some NI attention on this ....

NI .. any thoughts?  Any action already taking place?

Jarrod S. - have you sent rbergers code to R&D?  You might want to tack this on as an additional thing to check out.

Thanks for any responses.

Greycat

[DuffmanSays]

Greycat and rberger,

I will take a look at the code Greycat has recently posted and attempt to recreate this behavior here on my machine. Additionally, I spoke with Jarrod S. about the issue posted previously by rberger and unfortunately R&D could not take a look at the code because it was not an issue we could create from scratch. If I can recreate this new behavior, then we will be able to go to R&D for some deeper digging. In this case, I will make sure to include the description of the previous issue to be sure their efforts are thorough. Thank you both very much for your interest in these issues, and we apologize for any inconvenience they may have caused.

Mike

[Greycat]

Thanks Duffman ... I appreciate it  ... can you post to this thread if you are able to reproduce the problem and/or with any news on this issue ... thanks again for taking a look at this.

Greycat