|
This one rocks...
Private Sub Run_Click()
On Error Resume Next
OLE1.SourceDoc = pat & Grid
OLE1.SourceItem = pat & Grid
OLE1.Action = 1
DoEvents
OLE1.Action = 7
DoEvents
OLE1.Action = 10
End Sub
Greetings - Gajatko
Portable.NET is part of DotGNU, a project to build a complete Free Software replacement for .NET - a system that truly belongs to the developers.
|
|
|
|
|
gajatko wrote: On Error Resume Next
Thats VB for you.
If you're struggling developing software, then I'd recommend gardening.
|
|
|
|
|
norm .net wrote: That's
Yes, but 's can be expanded now to "was", not "is"
Greetings - Gajatko
Portable.NET is part of DotGNU, a project to build a complete Free Software replacement for .NET - a system that truly belongs to the developers.
|
|
|
|
|
I think you worded it incorrectly. Surely it should be "This one sucks..."
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
DoEvents: generating unexpected recursion since 1991.
|
|
|
|
|
Mike Dimmick wrote: DoEvents: generating unexpected recursion since 1991.
Commonly read in the VB forums:
"What's so bad about DoEvents?"
The early bird who catches the worm works for someone who comes in late and owns the worm farm. -- Travis McGee
|
|
|
|
|
The good: it allows other events to occur, so they don't end up massively queued up with your application unresponsive while you perform some complex task.
The bad: it allows all other events to occur, so you can end up re-entering the current block of code and ultimately end up with stack overflow. Also, if you happen to include it in a COM callback, or a paint handler when you've already made a COM call to another process, and one of the events that fires tries to make a COM call to another process, you get a 'cannot call out within message filter' error.
That one caused a lot of head-scratching, I can tell you. You end up having to break up your big routine littered with DoEvents into lots of little event handlers and somehow have a way of transferring control between them by some other object raising an event. Timers work, of course, but the minimum timer duration is about 15ms on Windows XP, which is eons in computing time. (I wrote a component in C++ which merely posts a message back to a hidden window, and raises an event when this occurs, cutting that down to tiny amounts.)
DoEvents : Generating unexpected recursion since 1991
|
|
|
|
|
Whats good about VB, absolutely nothing, zilch.
If you're struggling developing software, then I'd recommend gardening.
|
|
|
|
|
norm .net wrote: Whats good about VB, absolutely nothing, zilch.
My first post on this board is in vehement agreement with this wise poster.
Hello!
|
|
|
|
|
Welcome to the club of many hundreds of thousands of developers who share the same sentiments about VB.
Chuck Norris counted to infinity - twice.
|
|
|
|
|
It's a real shame they included this in .NET's WinForms implementation. I utterly rebuke any code that uses it.
Thank God they didn't such an easily abusable API in WPF.
In WinForms, if you really need to do lots of work and don't want to back up the UI thread, split up your work and execute it inside Application.Idle event. Much more scalable, no scary re-entry issues to deal with.
Or alternately just use a background thread.
|
|
|
|
|
I like the first line most.
Greetings from Germany
|
|
|
|
|
While trying to debug some legacy code, I ran into this unique take on an infinite loop:
''' <summary><br />
''' Initializes the trouble ticket display for stations<br />
''' </summary><br />
Public Sub initalizeTTick(ByVal stationID As String)<br />
'Database <br />
Dim db As New LabConsoleDB()<br />
<br />
Try<br />
Dim dr As DataRow = db.StationDetailedRecord(stationID)<br />
If dr Is Nothing Then Return<br />
<br />
'Populate the textbox for the trouble ticket<br />
txtTTick.Text = "Location:" & vbTab & stationID("stnName").ToString().ToUpper() & vbCrLf<br />
txtTTick.Text = txtTTick.Text & "Model:" & vbTab & dr("machManuf").ToString() & " " & dr("machModel").ToString() & vbCrLf<br />
txtTTick.Text = txtTTick.Text & "Serial:" & vbTab & stationID("machSerial").ToString() & vbCrLf<br />
txtTTick.Text = txtTTick.Text & "ICN:" & vbTab & dr("machICN").ToString() & vbCrLf<br />
txtTTick.Text = txtTTick.Text & "" & vbCrLf<br />
txtTTick.Text = txtTTick.Text & "Problem:" & vbTab & vbCrLf<br />
lblStnName.Text = dr("stnName").ToString().ToUpper()<br />
<br />
'Show the form<br />
Me.StartPosition = FormStartPosition.CenterScreen<br />
Me.Show()<br />
Catch<br />
Call initalizeTTick(stationID)<br />
End Try<br />
End Sub
|
|
|
|
|
Oooh. So - if I fail, I try me again and again. Well that's nice and defensive. I assume that the user sees a MessageBox saying Time Remaining. 1 second for the next 4 hours.
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
Well, being recursive it'll blow the stack... and the catch will fire again?
|
|
|
|
|
PIEBALDconsult wrote: and the catch will fire again
Hehe I read that as 'will catch fire again'!
I have no blog...
|
|
|
|
|
|
Isn't StackOverflowException one of those exception that doesn't get cought in ordinary catch?
edit:
Indeed it is (in .NET 2.0) Clickey[^]
-- modified at 6:59 Wednesday 19th September, 2007
[ My Blog] "Visual studio desperately needs some performance improvements. It is sometimes almost as slow as eclipse." - Rüdiger Klaehn "Real men use mspaint for writing code and notepad for designing graphics." - Anna-Jayne Metcalfe
|
|
|
|
|
Public Sub initalizeTTick(ByVal stationID As String)
stationID("stnName").ToString().ToUpper()
What the hell is that suppose to do?
|
|
|
|
|
Well, in this case, it throws a runtime error... which is caught by the exception.
Yes, not only is the code written so that if there are errors it recurses forever, it is written in such a way that this is GUARANTEED to happen.
|
|
|
|
|
|
You might want to create a trouble ticket for that error.... but i suggest you use a different program to log it just in case theres a problem when you initialize it
|
|
|
|
|
The stuff posted on here "just ain't so"...
Un-f-ing believable...
You guys have to start naming the companies and the projects for these things.
And, please state where these things are developed...location of the developer...
David
|
|
|
|
|
etkins wrote: "just ain't so"
Well a lot of this stuff would be too hard to make up, so it must be real.
etkins wrote: start naming the companies
Riiiiight.
etkins wrote: location of the developer
Most of them seem to be "the coder from hell."
BDF
|
|
|
|
|
etkins wrote: Un-f-ing believable...
You aren't programming for a long time, are you?
etkins wrote: You guys have to start naming the companies and the projects for these things.
Definitely not. This may get you in trouble - in most (all?) companies all code belongs to company. If you show it here, you are basicaly stealing. And it usually doesn't matter that you don't work for them anymore - it's well covered in the contract.
[ My Blog] "Visual studio desperately needs some performance improvements. It is sometimes almost as slow as eclipse." - Rüdiger Klaehn "Real men use mspaint for writing code and notepad for designing graphics." - Anna-Jayne Metcalfe
|
|
|
|