Serious weirdness going on here.

[PurpleYouko]

I have just come across the weirdest thing in some VB code that I am writing.

It should be quite straightforward. I have a textbox in which the user can type anything he wants then using a keypress event I transfer the current value of the textbox to another place after the user presses the enter key.

Seem normal enough? I thought so.

Here is the routine. (note the "a = a" lines are for highlighting as breakpoints and serve no actual function

Code: [Select]

Private Sub DataEntry_KeyPress(KeyAscii As Integer)
  If KeyAscii <> 13 Then Exit Sub
  If DataEntry.Text = "" Then
    DataEntry.Text = "0"
    a = a
  End If
  a = a
  DispGrid DataEntry.Text
  DataEntry.Visible = False
  DataEntry.Text = ""
End Sub
As you can see if the keypress returns anything other than 13 (enter) then the code just leaves the subroutine but when enter is pressed, the current value in the text box is sent to the "DispGrid" routine for output into a flexgrid object.

So what do you think will happen when I run the program?

What actually happens is that no matter what value is in the text box, "0" gets sent to "DispGrid". Weird huh?

It gets worse.

If I set the "a = a" statement inside the "If" statement as a breakpoint then run the program, it catches it and shows a value of "0" in the textbox as there should be if there was no text in it at all.

However (and this is where it gets bizarre) If I set the second "a = a" as the breakpoint and run the program, it skips the first breakpoint completely and the value in the textbox is shown to be whatever it was that I typed in. On continuing, the correct value is sent to "DispGrid" and the program works perfectly as designed.

This is the first, only and I hope last time that I have ever seen the outcome of a program change due to nothing more that highlighting a breakpoint in the code.

This is not supposed to happen  :blink:

[Numsgil]

There's a name for this type of bug.  I forget exactly...

It's some silly name like Mendelbug or Shrodingerbug, etc.  Bug only occurs when you run the program and not when you're debugging it.

[PurpleYouko]

Damn annoying pile of crap is my name for it.  :angry:

I have been chasing this darn thing for hours now.

Every time I run the program it screws up and outputs a zero but when I set the debug point anywhere except inside the conditional, the stupid thing works perfectly. <_<

I think it hates me. :(

[Numsgil]

Maybe it's your method for placing a catch line.  Instead of a = a try DoEvents.  See if that effects it at all.

Do you have "Option Explicit" at the top of your source, cause if not, it could be a typo bug (the worst kind).

[PurpleYouko]

No it isn't a typo. The code above was cut and pasted directly from the program itself.

I just made a stand alone test routine using exactly the same code and it works perfectly every time.

As for the a=a line. I have been using it for years to make a completely innocuous and useless piece of code that will work as a break point. never had it fail before.

I am NOT using option explicit because if I do then it crashes at my database queries every time I try to run them. The "Recordset" object in the ODBC setup is apparently incompatible with it. I can't dim "Recordset" because it is a reserved word but option explicit claims that it is undimensioned. Bit of a catch 22.  :wacko:

Anyway I have to go now. Time to go home to the wife, kids and my new kitten.  :bigginangel:

[Botsareus]

Try to see what DataEntery_Change() is doing... Debug.print it every time it changes...

This one even I never experianced although when vb ran out of memory it did wairder things...

[Numsgil]

I seem to remember reading about some bugs in Visual Basic being related to not using Option Explicit.  Something with how the program allocates variables at run time in debug mode vs. at compile time.

Sounds exactly like what you have going on here.  How to fix it?  I have no idea, as you say it's not as simple as including it.

[PurpleYouko]

Here is an even weirder thing.

I decided to include a separate routine that would still enter the value from the text box if the user simply clicks elsewhere on the form instead of physically pressing enter.

The best way to do this?

Use the "lostfocus" event.

How to enter the value into the flexgrid?

I know! :idea: Let's just call the "change" event routine and send a value of 13 into it so that it thinks somebody has pressed the enter key. That way it will just follow existing code without havinbg to write more stuff.

here is the routine as I wrote it.

Code: [Select]

Private Sub DataEntry_LostFocus()
  DataEntry_KeyPress 13
End Sub
Simple and elegent. And guess what. It works..... Perfectly. For some reason the bug in the "DataEntry_Keypress" routine doesn't rear it's head when the routine is entered this way. At least that proves that there isn't a typo in there.

I think I am just going to have to move the code into a third subroutine and call it from the keypress and the lostfocus events in the same way. Maybe they will both work then.

VB does some of the weirdest things without apparent reason. So many times I have had a program that runs perfectly for weeks then for some bizarre reason it just dies and returns some dumb-ass error. Nothing in the code has changed. It just plain doesn't work any more.  :wacko:

Maybe I DO need to learn C++

[PurpleYouko]

This is just nucking futs!!

It doesn't matter how many levels deep I go with calling subroutines from the keypress subroutine and it doesn't matter where or how I put breakpoints.

If there is a break point anywhere in the code (other than inside a conditional) then it works perfectly.
If there isn't then it doesn't. Period!

I had to get inventive in the end and add a global variable to hold the value of the textbox on a change event then tell it to kick out if the value after the change is null. Now it works but what a pain in the ass!