String Manipulation For List??

Wayne the more I think about it the more I see I need to detect the carraige feed and see the numbers immediately after it.

I can successfully locate the decimal point and the code I have written returns the numbers I need. However, these numbers can range from 0.00 to 999.99. Therefore trimming the statement according to the numbers may prove erroneous. A safer path would be to trim off the carraige return line feed if it is in the string, and therefore would make the string contain only the data returned. What do you think?

The SComm_Onreceive event is enabled by the ActiveX control. This is made possible by using WithEvents statement in the declaration section of Access 2002.
 
D,

You can do something like this to get the seven lines:

Code:
Dim ptr1 As Integer
Dim ptr2 As Integer
Dim Lines(7) As String

For ptr1 = 1 to 7
   ptr2 = Instr(1, mstgrDataContainer, Chr(10))
   Lines(ptr1) = Mid(mstgrDataContainer, 1, ptr2 - 1)
   mstgrDataContainer = Mid(mstgrDataContainer, ptr2 +2 )
   Next ptr1

This assumes that the 10 & 13 occur in that order otherwise
just change the Chr(10) to Chr(13)

Wayne
 
Thanks Wayne, that is very helpful indeed.

It is trimming the first letter off each line. I tried altering the line

Lines(ptr1) = Mid(mstgrDataContainer, 1, ptr2 - 1)

To ptr2-2,etc but it still trims by one letter???
 
D,

What happens if you do a MsgBox like a few posts ago
with the [sometext]?

I don't know what your "current" string looks like.

Wayne
 
I worked it out changed the line

ptr2 = Instr(1, mstgrDataContainer, Chr(13))

This causes the string to drop the last character instead of the first character this will do what I need.

Thanks for your help it has been well worthwhile
 
Just a follow up question.

Is it possible to work with an unknown line count. Or do I go back to working as a string which is not particularly efficent?
 
Realize I'm a day late and dollar short with this input, but after following this thread, think the following approach might assist:
Code:
Function strLook(dummyInput As String) As String
Dim strHold As String
Dim n As Integer

strHold = "100 Chlorine" & vbCrLf & "0.02-6 mg/l Cl2" & vbCrLf
strHold = strHold & "Profi -Mode: No" & vbCrLf & "2003-09-11 20:11:30" & vbCrLf
strHold = strHold & "Test No.: 1" & vbCrLf & "Code No.: 0" & vbCrLf
strHold = strHold & "0.05 mg/l free Cl2" & vbCrLf
strLook = strHold
End Function

Function FindVal(pInput As String, pDelim As String) As Double
Dim strHold As String
Dim n As Integer, intLen As Integer

' this calls strLook() which gives us a 7-line string to work with
strHold = RTrim(strLook("abc"))
intLen = Len(strHold)
'lop-off the last vbCrLf
strHold = Left(strHold, intLen - 1)
For n = 1 To 6
   strHold = Mid(strHold, InStr(strHold, pDelim) + 1)
Next n
FindVal = val(Left(strHold, InStr(strHold, " ") - 1))
End Function

If:
(1) The complete string is always seven lines long...
AND
(2) The target number is the first set of integers on the seventh line

...this should work.

After copying the above to a new module, test it from the debug window with:

? findval(strLook("abc"), vbCrLf)

It should return:

0.05
 
D,

(Nice code raskew, we needed you earlier).

Isn't it firmware that drives this beast? They can't change
the characteristics of the transmission without changing the
EPROM.

I'm not going to get too specific, because this approach might
not be needed.

You could declare a function that returns a Variant. This variant
will be an array, first entry is number of lines, subsequent
entries are input lines from your device.

Code:
Dim Lines(1) As Variant
Lines = 0
Temp = ""
For ptr = q to Len(mstgrDataContainer)
   If Mid(mstgrDataContainer, ptr, 1) = Chr(10) Then
      Lines = Lines + 1
      ReDim Preserve Lines array
      Lines(Line) = Temp
      Temp = ""
   Else
      Temp = Temp & Mid(mstgrDataContainer, ptr, 1)
   End If
   Next Ptr

Just some thoughts,

The main routines code, just calls the function and retrieves
the value.

Wayne
 
Mr. Tiger-

I agree with Wayne.

In order to resolve this, think we need to pin-down what the device is providing, and in what format.

If we can get a firm handle on that, think this a very solvable situation.

Bob

p.s. Wayne: Grew up in Santa Barbara, lived in Camarillo for 2+ years while commuting to Wilshire Blvd. in downtown L.A. There's not enough money available to persuade me to move back to CA -- left before the housing went amuck and sold my 4 bedroom house, with pool, for $31K.
 
Bob,

My pool cost $31K ... Just kidding, don't even have a pool.
Love it here though. You wouldn't believe how much this
area has grown. I've been here twenty years and it kind
of sneaks up on you. They keep building shopping malls
and housing tracts. Wouldn't want to live anywhere else
though.

As to D's problem though. I wish I could play around
with the device for a while. It obviously has been made
to work with Access, or at least interact with other
software, because he already has his interrupt routine.

I didn't want to get into too much detail without more
info. I hate blind alleys.

Won't D be happy that we're still working on this.

Wayne

p.s. I'm still mystified by the behaviour of the
Randomize call that doesn't (sometimes).
 
Her we go then.

Most of the time the instrument will output 5 lines in final configuration. In the current mode it spits out 7 lines. For most tests.

For some tests it spits out 8 lines, 9 lines and may even go to 10 lines. In the case of these tests we are only interested in one parameter, however, in these tests multi parameters are returned. My thought was to tell the code which line contained the result in the calibration forms.
 
D,

My approach from two posts ago should handle that. The
function will return an array with the count of lines. The
calling software just has to know which line contains
the data.

Let me know if you need help coding.

Wayne
 
Thanks for your help again. I just really needed a hand on the approach. I am not sure I want to go this way at all, certainly in the short term.

The instrument is designed to work with a computer. Originally the manufacturer intended to return data to Excel (although I only found this out recently).

To be honest with your help and what I'd already worked out this has gone from a nightmare to a bit of a dream. The instrument behaves itself, the software behaves itself and the ActiveX behaves itself (moost of the time).

The biggest challenge now is the methods. In some cases methods for tests I would normally consider mandatory take 5 minutes and can't be bypassed as there is a built in timer. This is not acceptable when you are trying to conduct 20 - 40 tests an hour. So I have had to come up with an approach using pop up form to allow either input from instrument or input manually.

Thanks again it been good.
 

Users who are viewing this thread

Back
Top Bottom