Obviously. Maybe read the answer again and try to understand? If your INPUT never changes then it will work. But if you EVER decide to transmit more data then the code will fail.
[quote]It is SOLVED.
There are NO Glitches anymore. Why would there be? This works PERFECT.[/quote]
Not understanding a problem and misunderstanding how MID works is one thing. Can happen to anybody.
Claiming there is no problem and pretending the solution is perfect just boggles the mind
P.S. if someone like Kem tells you there is a bug, then it pays to listen
Markus, That is ridiculous. And absurd to an extreme point that I have no choice than to call you an absolute dickhead.
Yeah. but I love you anyways 
So I guess you have no thoughts for yourself?
This forum needs a hubris channel.
Sometimes, a deep breath and a short walk suffice to see the light. Works for me anyway.
THAT might well be true. Doesn’t make me wrong.
On the other hand it is a dead certainty that you are not right 
They’re right, Steve. It only works for you now because of a happy accident, and relying on happy accidents to make your code work usually ends up biting you eventually. It should be
Mid(modelNumber, location, 13)You want to grab 13 characters, beginning at location.
Sorry Markus, and I apologise for saying that.
I’m getting frustrated because no-one seems to understand where I’m coming from. So I will attempt to set the record straight.
No-one but me will deliver the (model number) data being read from the external device. Therefore it will always be correct. It will ALWAYS be 13 characters long, although it may appear in a different location. If that fails (ie. not my device) then the device name is GENERIC.
I’ve done enough testing and it all seems to work as expected and I don’t see it failing. If it did fail, then it falls through to GENERIC anyway.
I will test again this evening. I certainly don’t want this working via a happy accident.
It ONLY works because the info you grab is at the END of the string. You tell it to grab position + 13 characters but as there are only 13 characters that is what you get.
If in the future you decide you need to send more data and the desired info is NOT at the end anymore then your code will fail. Simple as that. It is generally considered to be bad code when the code relies on unique circumstances for it to work correctly.
It also demonstrates that you did not really understand how your code works.
Both are not ideal which is why everyone is trying to help you.
I honestly don’t mean to pile on here, but if that is the case, then the most appropriate thing to do would be to leave off the length altogether. That means, from location to the end of the string. That is much more clear than location+13, which will leave you scratching your head in five years when you revisit the code and wonder, “what does that mean?”
P.S. On the contrary, weve all been there. But over time you will build up a collection of reusable code so code needs to be as future proof as possible.
Thats also why I would not leave the length parameter out as Tim suggested as that too makes it less future proof (unless you always want your code ro return everything from location to the end of the string).
Thanks EVERYONE.
Yes, the way I had it (location+13) , would have returned a longer string if there were any characters after modelName. Which would have been a big fat fail.
Although that scenario shouldn’t occur in the incoming data it certainly wasn’t the correct way to go about it and incorrect usage of the Mid function. I don’t know why I thought I had to have (location+13).
You were correct Markus, I didn’t read the documentation properly and missed the vital information:
If It wasn’t pointed out to me, I would have assumed I was using Mid correctly and it would have caused issues later with something else.
So, thanks once again.