memory error

Greetings

I have dumb question.  I have a very small dll that pops up a data entry
form.  The user enters the data and hits search.  I am interfacing with
another program that searches a database on a main frame somewhere.  Then I
screen scrape the other program and depending on what I find I either return
the information or have to send the other program some keystrokes and wait
for another screen.  This process can take up to 30 seconds from start to
finish.

I was using Me.MousePointer = vbHourglass to let the user know there was
something going on and not to worry about hanging up the computer.  This dll
gets called and released by another process over and over again all day
long,

For some reason with the mouse pointer line in there the form my dll was
crashing and I was logging lots of Out Of Memory errors number 7.  Usually
after about 4 or 5 calls.  I Googled the error message and only came up with
a bunch of results about  FM20.DLL or large amounts of forms or controls.
With that line commented out the error messages are no longer logged and it
works great.

Can anyone explain what might be going on? or another way besides a message
box to keep the user entertained?

thanks

Bob

PS

the only references listed are
vba6.dll
msvbvm60.dll\3
VB6.OLB
stdole2.tlb
scrunn.dll

Controls
mscomctl.ocx

Hmmm ... does the DLL present an interface (the data entry screen) or just
perform the work in the background? If the latter why is it setting the
mousepointer?

I really have to wonder if that - the mousepointer line - is really causing
the problem. I suspect that something else is actually causing it, and the
break is showing the mousepointer line as the problem.

Do you have error checking enabled in the routine with the mousepointer
line, and that routine calls another that does not have error trapping?  If
this is the case, the called routine (or a routine called from that second
routine without an error trap) may be generating the error. The result you
would see is a break on the line following the code that called the problem
routine, misleading you to believe that was the problem.

--


Randy Birch
MS MVP Visual Basic
http://vbnet.mvps.org/


"Bob Cummings" <rcummings@wausaufs.com> wrote in message
news:eMqEf%23JvEHA.3624@TK2MSFTNGP09.phx.gbl...
: Greetings
:
: I have dumb question.  I have a very small dll that pops up a data entry
: form.  The user enters the data and hits search.  I am interfacing with
: another program that searches a database on a main frame somewhere.  Then
I
: screen scrape the other program and depending on what I find I either
return
: the information or have to send the other program some keystrokes and wait
: for another screen.  This process can take up to 30 seconds from start to
: finish.
:
: I was using Me.MousePointer = vbHourglass to let the user know there was
: something going on and not to worry about hanging up the computer.  This
dll
: gets called and released by another process over and over again all day
: long,
:
: For some reason with the mouse pointer line in there the form my dll was
: crashing and I was logging lots of Out Of Memory errors number 7.  Usually
: after about 4 or 5 calls.  I Googled the error message and only came up
with
: a bunch of results about  FM20.DLL or large amounts of forms or controls.
: With that line commented out the error messages are no longer logged and
it
: works great.
:
: Can anyone explain what might be going on? or another way besides a
message
: box to keep the user entertained?
:
: thanks
:
: Bob
:
: PS
:
: the only references listed are
: vba6.dll
: msvbvm60.dll\3
: VB6.OLB
: stdole2.tlb
: scrunn.dll
:
: Controls
: mscomctl.ocx
:
:
:
:
:
:
:

Thanks for the quick reply
The dll does both: present the data entry screen and work in the background.
This is my first professional project and this is how they told me to do it.
I have no idea if this is good form or not. Any how here are snippets of the
actual code. The Me.MousePointer was line 40 and that was the line I was
logging

seems to have lost formatting in cutting and paste

10     On Error GoTo search_Error
20     WriteLog "inside the search method of the form"

Dim success As Boolean
Dim mySearchInfo(9) As String
30     success = True
'        Me.MousePointer = vbHourglass
40     If checkTextBoxes Then

more follows but there are the lines before and after
chechTextBoxes follows

Private Function checkTextBoxes() As Boolean
Dim Result As Boolean
Dim ctrl As Control
Result = False
'check to see if something is entered in at least one field
For Each ctrl In Me.Controls
If TypeOf ctrl Is TextBox Then
If ctrl.Text <> "" Then
Result = True
End If
End If
Next ctrl

'no partial searches on phone number
If Me.txtPhone.Text <> "" And Len(txtPhone.Text) <> 10 Then
Result = False
MsgBox "The Phone Number seach needs 10 characters", vbCritical,
"Error in             Phone Search"
End If
checkTextBoxes = Result
End Function

Does this help at all?
Thanks
bob
"Randy Birch" <rgb_removethis@mvps.org> wrote in message
news:ukfbGGKvEHA.940@TK2MSFTNGP14.phx.gbl...
> Hmmm ... does the DLL present an interface (the data entry screen) or just
> perform the work in the background? If the latter why is it setting the
> mousepointer?
>
> I really have to wonder if that - the mousepointer line - is really
causing
> the problem. I suspect that something else is actually causing it, and the
> break is showing the mousepointer line as the problem.
>
> Do you have error checking enabled in the routine with the mousepointer
> line, and that routine calls another that does not have error trapping?
If
> this is the case, the called routine (or a routine called from that second
> routine without an error trap) may be generating the error. The result you
> would see is a break on the line following the code that called the
problem
> routine, misleading you to believe that was the problem.
>
> --
>
>
> Randy Birch
> MS MVP Visual Basic
> http://vbnet.mvps.org/
>
>
> "Bob Cummings" <rcummings@wausaufs.com> wrote in message
> news:eMqEf%23JvEHA.3624@TK2MSFTNGP09.phx.gbl...
> : Greetings
> :
> : I have dumb question.  I have a very small dll that pops up a data entry
> : form.  The user enters the data and hits search.  I am interfacing with
> : another program that searches a database on a main frame somewhere.
Then
> I
> : screen scrape the other program and depending on what I find I either
> return
> : the information or have to send the other program some keystrokes and
wait
> : for another screen.  This process can take up to 30 seconds from start
to
> : finish.
> :
> : I was using Me.MousePointer = vbHourglass to let the user know there was
> : something going on and not to worry about hanging up the computer.  This
> dll
> : gets called and released by another process over and over again all day
> : long,
> :
> : For some reason with the mouse pointer line in there the form my dll was
> : crashing and I was logging lots of Out Of Memory errors number 7.
Usually
> : after about 4 or 5 calls.  I Googled the error message and only came up
> with
> : a bunch of results about  FM20.DLL or large amounts of forms or
controls.
> : With that line commented out the error messages are no longer logged and
> it
> : works great.
> :
> : Can anyone explain what might be going on? or another way besides a
> message
> : box to keep the user entertained?
> :
> : thanks
> :
> : Bob
> :
> : PS
> :
> : the only references listed are
> : vba6.dll
> : msvbvm60.dll\3
> : VB6.OLB
> : stdole2.tlb
> : scrunn.dll
> :
> : Controls
> : mscomctl.ocx
> :
> :
> :
> :
> :
> :
> :
>

Comment out your On Error GoTo search_Error line, leave the rodentpointer
line in, and run. See if it fails.  Then add logging code to the routine(s)
called from that routine and test again. (If running in the IDE also ensure
'break on all errors' under tools>options is checked.)

It's possible the code is failing on in the WriteLog routine.

Does it fail more often when invalid data is entered, or good data is
entered, or does that aspect not matter?  I'm wondering about the Messagebox
call in checkTextBoxes.


BTW, a couple of other thoughts ...

a) it's more efficient to test for length for a string, rather than "", e.g.

If Len (Me.txtPhone.Text) >0 and ...

rather than :

If Me.txtPhone.Text <> "" and ...

Ditto ...

Len(ctrl.Text) <> 0

... instead of:

ctrl.Text <> ""

b) Is not the test:

if Me.txtPhone.Text <> "" And Len(txtPhone.Text) <> 10 then ...

redundant?  That is, if you must have a 10-char entry before proceeding, as
your comment implies, then the test for "" is unnecessary ... the data is
either 10 characters long (valid) or it is not (invalid). This means the
test could be simply:

If Len(txtPhone.Text) <> 10 then
..
end if


c) Also, it is unnecessary to initialize Result = False in the
checkTextBoxes routine as Result is declared as a local variable, which is
automagically initialized to 0 in the Dim statement.

d) You comment by the code:

For Each ctrl In Me.Controls
If TypeOf ctrl Is TextBox Then
If ctrl.Text <> "" Then
Result = True
End If
End If

... implies you only care if one of the n textboxes has data. If this is th
e
case, then you should have an Exit For after the Result=True line, otherwise
the code will loop through all the controls even if the condition has been
met. This just wastes cycles.

But don't make any of these change right now ... just comment out the error
trap to learn where the code fails. Fix that, then optimize the code.

That's all I can see in a couple of minutes of review (it's 1am here and
5:30 comes way too fast). Try disabling the error-trap and proceed from
there. I'll be back online around 8pm tomorrow (EDT).

--


Randy Birch
MS MVP Visual Basic
http://vbnet.mvps.org/


"Bob Cummings" <rcummings@wausaufs.com> wrote in message
news:%23KG4WPKvEHA.1292@TK2MSFTNGP10.phx.gbl...
: Thanks for the quick reply
: The dll does both: present the data entry screen and work in the
background.
: This is my first professional project and this is how they told me to do
it.
: I have no idea if this is good form or not. Any how here are snippets of
the
: actual code. The Me.MousePointer was line 40 and that was the line I was
: logging
:
: seems to have lost formatting in cutting and paste
:
: 10     On Error GoTo search_Error
: 20     WriteLog "inside the search method of the form"
:
:         Dim success As Boolean
:         Dim mySearchInfo(9) As String
: 30     success = True
: '        Me.MousePointer = vbHourglass
: 40     If checkTextBoxes Then
:
: more follows but there are the lines before and after
: chechTextBoxes follows
:
: Private Function checkTextBoxes() As Boolean
:     Dim Result As Boolean
:     Dim ctrl As Control
:     Result = False
:         'check to see if something is entered in at least one field
:         For Each ctrl In Me.Controls
:             If TypeOf ctrl Is TextBox Then
:                 If ctrl.Text <> "" Then
:                     Result = True
:                 End If
:         End If
:     Next ctrl
:
:     'no partial searches on phone number
:     If Me.txtPhone.Text <> "" And Len(txtPhone.Text) <> 10 Then
:         Result = False
:         MsgBox "The Phone Number seach needs 10 characters", vbCritical,
: "Error in             Phone Search"
:     End If
:     checkTextBoxes = Result
: End Function
:
: Does this help at all?
: Thanks
: bob
: "Randy Birch" <rgb_removethis@mvps.org> wrote in message
: news:ukfbGGKvEHA.940@TK2MSFTNGP14.phx.gbl...
: > Hmmm ... does the DLL present an interface (the data entry screen) or
just
: > perform the work in the background? If the latter why is it setting the
: > mousepointer?
: >
: > I really have to wonder if that - the mousepointer line - is really
: causing
: > the problem. I suspect that something else is actually causing it, and
the
: > break is showing the mousepointer line as the problem.
: >
: > Do you have error checking enabled in the routine with the mousepointer
: > line, and that routine calls another that does not have error trapping?
: If
: > this is the case, the called routine (or a routine called from that
second
: > routine without an error trap) may be generating the error. The result
you
: > would see is a break on the line following the code that called the
: problem
: > routine, misleading you to believe that was the problem.
: >
: > --
: >
: >
: > Randy Birch
: > MS MVP Visual Basic
: > http://vbnet.mvps.org/
: >
: >
: > "Bob Cummings" <rcummings@wausaufs.com> wrote in message
: > news:eMqEf%23JvEHA.3624@TK2MSFTNGP09.phx.gbl...
: > : Greetings
: > :
: > : I have dumb question.  I have a very small dll that pops up a data
entry
: > : form.  The user enters the data and hits search.  I am interfacing
with
: > : another program that searches a database on a main frame somewhere.
: Then
: > I
: > : screen scrape the other program and depending on what I find I either
: > return
: > : the information or have to send the other program some keystrokes and
: wait
: > : for another screen.  This process can take up to 30 seconds from start
: to
: > : finish.
: > :
: > : I was using Me.MousePointer = vbHourglass to let the user know there
was
: > : something going on and not to worry about hanging up the computer.
This
: > dll
: > : gets called and released by another process over and over again all
day
: > : long,
: > :
: > : For some reason with the mouse pointer line in there the form my dll
was
: > : crashing and I was logging lots of Out Of Memory errors number 7.
: Usually
: > : after about 4 or 5 calls.  I Googled the error message and only came
up
: > with
: > : a bunch of results about  FM20.DLL or large amounts of forms or
: controls.
: > : With that line commented out the error messages are no longer logged
and
: > it
: > : works great.
: > :
: > : Can anyone explain what might be going on? or another way besides a
: > message
: > : box to keep the user entertained?
: > :
: > : thanks
: > :
: > : Bob
: > :
: > : PS
: > :
: > : the only references listed are
: > : vba6.dll
: > : msvbvm60.dll\3
: > : VB6.OLB
: > : stdole2.tlb
: > : scrunn.dll
: > :
: > : Controls
: > : mscomctl.ocx
: > :
: > :
: > :
: > :
: > :
: > :
: > :
: >
:
:

"Randy Birch" <rgb_removethis@mvps.org> wrote

> b) Is not the test:
>
>   if Me.txtPhone.Text <> "" And Len(txtPhone.Text) <> 10 then ...
>
> redundant?

Its OK the way it is....

If you only use Len(...) <> 10 then the user gets the warning even
when they want to leave it blank. The warning is only needed when
they've added something to the textbox that wasn't 10 characters long.

LFS

"Bob Cummings" <rcummings@wausaufs.com> wrote

> I have dumb question.  I have a very small dll that pops up a data entry
> form.  The user enters the data and hits search.  I am interfacing with
> another program that searches a database on a main frame somewhere.  Then 
I
> screen scrape the other program and depending on what I find I either retu
rn
> the information or have to send the other program some keystrokes and wait
> for another screen.  This process can take up to 30 seconds from start to
> finish.

I be suspicious of your screen scraping code before looking at the mouse
pointer causing errors.  Screen scraping could involve latching on to handle
s,
or other resources, that should be fully inspected for proper operation.  Th
en
there is the other side of it, where you contact that DB program.  I'd sugge
st
that you look those over very carefully to make sure everything you create
gets destroyed, and every reference you grab, gets released, etc...

I am not trying to suggest that you have anything wrong, but I would suggest
that an intrinsic VB command is usually pretty safe, under normal conditions
.
I'd be surprised if setting the mouse pointer was the cause of the trouble, 
and
not merely a side effect of other problems....

Good luck!
LFS

"Larry Serflaten" <serflaten@usinternet.com> wrote
>
> "Randy Birch" <rgb_removethis@mvps.org> wrote
> 
>
> Its OK the way it is....

Oops, I meant both tests are needed.  It would be better to use the
Len function for both tests:

If Len(txtPhone.Text) > 0 And Len(txtPhone.Text) <> 10 Then ...

But now, what if they add spaces to the phone number???

;-)
LFS

> > > b) Is not the test: 
>
> Oops, I meant both tests are needed.  It would be better to use the
> Len function for both tests:
>
> If Len(txtPhone.Text) > 0 And Len(txtPhone.Text) <> 10 Then ...

I know the OP included a logical test equivalent to the first part of
your If statement, but I would assume that for the purpose
(Function==>checkTextBoxes), a length of 0 should generate the same
message as an entry not containing 10 characters in it. So, I would
guess the above could be written like this instead...

If Len(txtPhone.Text) <> 10 Then ...


> But now, what if they add spaces to the phone number???

Assuming I'm right about not needing the test for a length of 0, this
should handle the "extra spaces" problem...

If Len(Replace(txtPhone.Text, " ", "") <> 10 Then ...

But what if they added dashes in-between the number groupings; or used
parentheses around the area code? Of course, additional Replace function
calls could be added to handle those conditions. Is there any other
"neatening" symbols that are standard in a phone number?


Rick - MVP

> >>>>b) Is not the test: 
of 
this 
used 
function 
> Wow is it nice to see so much help.  Maybe it is overkill, anyhow in
> school the instructor taught us when looking for only numeric or only
> character input, we should be validating on the key press event. That
> was supposed to make the validation less intrusive for the user.  So
on
> every keypress in the phone number and zip code text boxes I only
allow
> numeric entries and an error message if they try to do anything else.
I
> could have used a masked edit control I suppose instead.  Anyhow I am
> not worried about spaces or dashes because I know there is only
numeric
> data in certain text boxes.

While your instructor is having you validate numeric entry in the
KeyPress event, you should keep in the back of your mind (for if and
when you go out into the "real" programming world) that parsing in the
KeyPress event is not fully robust... your users will always be able to
Paste non-numeric data into the TextBox. While this is beyond what your
instructor is looking for, and perhaps beyond your current level in VB,
here is a link to code I've posted in the past which handles the Paste
problem as well. Right now, this should be considered as "information
only", but you might want to keep a reference to it if you plan on
pursuing programming full time.

http://groups.google.com/groups?hl=...r />
ors%3Drot
 hstein%26as_scoring%3Dd%26lr%3D%26num%3D
100%26hl%3Den

Rick - MVP

"Bob Cummings" <rancho@dwave.net> wrote in message
news:O4TgARQvEHA.4072@TK2MSFTNGP15.phx.gbl
<cut>
> Wow is it nice to see so much help.  Maybe it is overkill, anyhow in
> school the instructor taught us when looking for only numeric or only
> character input, we should be validating on the key press event.

Like many, your instructor is overlooking the ability to copy & paste which
bypasses the keypress event.  The Change event is more useful but be careful
to use some sort of non-intrusive validation like changing background or
border colors or displaying a mark next to the entry area rather than
interrupting the user with a msgbox.

In general, I find that form-level validation (i.e. checking all fields when
the user clicks SAVE) is the best way to go with any field-level validation
done only as a supplement.

--
Reply to the group so all can participate
VB.Net... just say "No"