Author |
Message |
Mark Burn #1 / 15
|
VB6: With...End With time bomb?
My poor addled memory dimly recalls some sort of big problem regarding With...end With blocks in VB. I seem to recall some circumstance where using With...End With in certain constructs could result in GPFs. Here's what I'm trying to do in a class module: This class is being constructed to be callable from Acess(97/2xxx) as well as VB6 and is in an ActiveX DLL. We therefore wish the class to be DAO/ADO ambidextrous. At one point in the code, it'd be efficient for us to do this type of construct: Dim oDAORs as DAO.Recordset Dim oADORs as ADODB.Recordset ...<snip>... If DAO then <blah blah open the recordset blah> With oDAORs '<== with block starts within if...endif block Elseif ADO then <blah blah open the recordset blah> With oADORs '<== with block starts within if...endif block Endif <with variable references outside of if...endif block> if .fields(FieldEnumVal).value...<blah blah> end with '<== End with block outside of if...endif block If DAO then <blah blah close stuff> ElseIf ADO then <blah blha close stuff> Endif Will this get a kosher seal of approval from the VB6 compiler and runtime, or will Mr. BSOD greet us?
|
Tue, 14 Sep 2004 06:08:21 GMT |
|
|
#2 / 15
|
VB6: With...End With time bomb?
|
Fri, 19 Jun 1992 00:00:00 GMT |
|
|
Douglas Marquard #3 / 15
|
VB6: With...End With time bomb?
Mark: Quote: > My poor addled memory dimly recalls some sort of big problem regarding > With...end With blocks in VB.
The only issue I recall, is that your code must reach the "End With" statement to release the reference to the object; otherwise, the reference will hang around until you app exits -- though I am not 100% sure on this. Quote: > If DAO then > <blah blah open the recordset blah> > With oDAORs '<== with block starts within if...endif block > Elseif ADO then > <blah blah open the recordset blah> > With oADORs '<== with block starts within if...endif block > Endif
I doubt if that will work (it may, I have never tried it), but imho you would be better off separating the two distinct recordsets, i.e. If DAO Then With oDAORs ...etc End With ElseIf ADO Then With oADORs ...etc End With End If Just my $.02 Doug.
|
Tue, 14 Sep 2004 06:33:08 GMT |
|
|
Mark Burn #4 / 15
|
VB6: With...End With time bomb?
Quote: > Mark: > > My poor addled memory dimly recalls some sort of big problem regarding > > With...end With blocks in VB. > The only issue I recall, is that your code must reach the "End With" statement > to release the reference to the object; otherwise, the reference will hang around > until you app exits -- though I am not 100% sure on this. > > If DAO then > > <blah blah open the recordset blah> > > With oDAORs '<== with block starts within if...endif block > > Elseif ADO then > > <blah blah open the recordset blah> > > With oADORs '<== with block starts within if...endif block > > Endif > I doubt if that will work (it may, I have never tried it), > but imho you would be better off separating the two > distinct recordsets, i.e. > If DAO Then > With oDAORs > ...etc > End With > ElseIf ADO Then > With oADORs > ...etc > End With > End If
Yeah, I'm just trying to avoid duplicating what would otherwise be 2 very big completely identical code blocks for maintenance reasons as some of that code will likely get modified, and I just hate having to do that twice...and I refuse to use gosub and I don't want the overhead of a function... Although,...perhaps this _is_ one of those rare proper applications of gosub...Hmmm....
|
Tue, 14 Sep 2004 06:38:32 GMT |
|
|
Douglas Marquard #5 / 15
|
VB6: With...End With time bomb?
Hi Mark: Quote: > Yeah, I'm just trying to avoid duplicating what would otherwise be 2 very > big completely identical code blocks for maintenance reasons as some of that > code will likely get modified, and I just hate having to do that twice
What about late binding? If the speed at which the code executes is okay then do that should work, i.e. Dim obj As Object Dim ..etc ...etc If DAO Then Set obj = oDAORs ElseIf ADO Set obj = oADORs End If With obj ...etc End With Doug.
|
Tue, 14 Sep 2004 06:57:11 GMT |
|
|
Craig Power #6 / 15
|
VB6: With...End With time bomb?
Quote:
> Yeah, I'm just trying to avoid duplicating what would otherwise be 2 very > big completely identical code blocks for maintenance reasons as some of that > code will likely get modified, and I just hate having to do that twice...and > I refuse to use gosub and I don't want the overhead of a function... > Although,...perhaps this _is_ one of those rare proper applications of > gosub...Hmmm....
I seem to recall hearing that performance for gosub is atrocious, so if you're worried about performance, you'd be better off using a function call.
|
Tue, 14 Sep 2004 07:03:21 GMT |
|
|
Mark Burn #7 / 15
|
VB6: With...End With time bomb?
Quote:
> > Yeah, I'm just trying to avoid duplicating what would otherwise be 2 very > > big completely identical code blocks for maintenance reasons as some of that > > code will likely get modified, and I just hate having to do that twice...and > > I refuse to use gosub and I don't want the overhead of a function... > > Although,...perhaps this _is_ one of those rare proper applications of > > gosub...Hmmm.... > I seem to recall hearing that performance for gosub is atrocious, so if > you're worried about performance, you'd be better off using a function > call.
My recollection is just exactly the opposite. There was a time (VB4?) that gosub did indeed suck performance wise, but think I recall Dan Barclay saying that it was fixed even before VB5 shipped.
|
Tue, 14 Sep 2004 07:40:50 GMT |
|
|
The New iSoftware Compan #8 / 15
|
VB6: With...End With time bomb?
Well in .NET, if you are thinking about it, GoSub is no longer supported.
Quote:
> > > Yeah, I'm just trying to avoid duplicating what would otherwise be 2 > very > > > big completely identical code blocks for maintenance reasons as some of > that > > > code will likely get modified, and I just hate having to do that > twice...and > > > I refuse to use gosub and I don't want the overhead of a function... > > > Although,...perhaps this _is_ one of those rare proper applications of > > > gosub...Hmmm.... > > I seem to recall hearing that performance for gosub is atrocious, so if > > you're worried about performance, you'd be better off using a function > > call. > My recollection is just exactly the opposite. There was a time (VB4?) that > gosub did indeed suck performance wise, but think I recall Dan Barclay > saying that it was fixed even before VB5 shipped.
|
Tue, 14 Sep 2004 08:28:34 GMT |
|
|
Mark Burn #9 / 15
|
VB6: With...End With time bomb?
Quote: > Well in .NET, if you are thinking about it, GoSub is no longer supported.
Yeah, I know. That's why I was trying to avoid it.
|
Tue, 14 Sep 2004 08:29:54 GMT |
|
|
Stephen Mart #10 / 15
|
VB6: With...End With time bomb?
Since the overhead of a function call is on the order of 1 microsecond and the timing of dataset creation and access is generally on the order of milliseconds (or more) "avoiding the overhead of a function" seems a little odd. On Thu, 28 Mar 2002 17:38:32 -0500, "Mark Burns" Quote:
>> Mark: >> > My poor addled memory dimly recalls some sort of big problem regarding >> > With...end With blocks in VB. >> The only issue I recall, is that your code must reach the "End With" >statement >> to release the reference to the object; otherwise, the reference will hang >around >> until you app exits -- though I am not 100% sure on this. >> > If DAO then >> > <blah blah open the recordset blah> >> > With oDAORs '<== with block starts within if...endif block >> > Elseif ADO then >> > <blah blah open the recordset blah> >> > With oADORs '<== with block starts within if...endif block >> > Endif >> I doubt if that will work (it may, I have never tried it), >> but imho you would be better off separating the two >> distinct recordsets, i.e. >> If DAO Then >> With oDAORs >> ...etc >> End With >> ElseIf ADO Then >> With oADORs >> ...etc >> End With >> End If >Yeah, I'm just trying to avoid duplicating what would otherwise be 2 very >big completely identical code blocks for maintenance reasons as some of that >code will likely get modified, and I just hate having to do that twice...and >I refuse to use gosub and I don't want the overhead of a function... >Although,...perhaps this _is_ one of those rare proper applications of >gosub...Hmmm....
Stephen Martin EMSoft Solutions Inc. Toronto, ON
|
Sat, 18 Sep 2004 06:08:33 GMT |
|
|
Joe #11 / 15
|
VB6: With...End With time bomb?
Quote:
> Since the overhead of a function call is on the order of 1 microsecond > and the timing of dataset creation and access is generally on the > order of milliseconds (or more) "avoiding the overhead of a function" > seems a little odd.
Unfortunately, using my wrapper classes, even just the FakeField stuff and ditching FakeRecordset, will add /lots/ of little implicit function calls, but that's much better than a bug within one version of some duplicated code but not the other(s)... -- Joe Foster <mailto:jlfoster%40znet.com> DC8s in Spaace: <http://www.xenu.net/> WARNING: I cannot be held responsible for the above They're coming to because my cats have apparently learned to type. take me away, ha ha!
|
Sat, 18 Sep 2004 08:48:33 GMT |
|
|
Craig Power #12 / 15
|
VB6: With...End With time bomb?
Quote:
> > I seem to recall hearing that performance for gosub is atrocious, so if > > you're worried about performance, you'd be better off using a function > > call. > My recollection is just exactly the opposite. There was a time (VB4?) that > gosub did indeed suck performance wise, but think I recall Dan Barclay > saying that it was fixed even before VB5 shipped.
It's entirely possible that my information was out of date or was never accurate.
|
Sun, 26 Sep 2004 04:58:12 GMT |
|
|
Joe #13 / 15
|
VB6: With...End With time bomb?
Quote:
> > > I seem to recall hearing that performance for gosub is atrocious, so if > > > you're worried about performance, you'd be better off using a function > > > call. > > My recollection is just exactly the opposite. There was a time (VB4?) that > > gosub did indeed suck performance wise, but think I recall Dan Barclay > > saying that it was fixed even before VB5 shipped. > It's entirely possible that my information was out of date or was > never accurate.
Read and weep: URL:http://support.microsoft.com/default.aspx?scid=kb;;q174808 -- Joe Foster <mailto:jlfoster%40znet.com> Sign the Check! <http://www.xenu.net/> WARNING: I cannot be held responsible for the above They're coming to because my cats have apparently learned to type. take me away, ha ha!
|
Sun, 26 Sep 2004 09:06:27 GMT |
|
|
Craig Power #14 / 15
|
VB6: With...End With time bomb?
Quote:
> > > > I seem to recall hearing that performance for gosub is atrocious, so if > > > > you're worried about performance, you'd be better off using a function > > > > call. > > > My recollection is just exactly the opposite. There was a time (VB4?) that > > > gosub did indeed suck performance wise, but think I recall Dan Barclay > > > saying that it was fixed even before VB5 shipped. > > It's entirely possible that my information was out of date or was > > never accurate. > Read and weep: > URL:http://support.microsoft.com/default.aspx?scid=kb;;q174808
Thanks. It appears that my information is indeed accurate. Offhand, it seems a little odd that performance should be so bad, but I've never tried doing a comparison between a function call example and the way I'd choose to implement GoSub in C++.
|
Mon, 27 Sep 2004 01:01:39 GMT |
|
|
Craig Power #15 / 15
|
VB6: With...End With time bomb?
Quote:
> > Read and weep: > > URL:http://support.microsoft.com/default.aspx?scid=kb;;q174808 > Thanks. It appears that my information is indeed accurate. > Offhand, it seems a little odd that performance should be so bad, > but I've never tried doing a comparison between a function call > example and the way I'd choose to implement GoSub in C++.
OK, I just did a fake of GoSub in C++ - and it's the most pessimistic implementation possible, as it assumes an arbitrary number of nested gosubs, and I didn't pre-allocate my return location stack. (For the test case at hand, it could be modeled as merely two gotos, but that would be an optimization for usage.) My C++ results - 10 ms for inline code, 40 ms for a function call (same as with compiled VB), and 140 ms for GoSub - about 18% of the 761 ms I got with compiled VB (which was worse than the ~400 ms interpreted). Conclusion: if they wrote the code generation for native code for GoSub / Return from scratch, they did a very poor job of it. And since I was using C++, I couldn't use a cool assembly trick like pushing the departure address onto the stack and then popping it and jumping back there, which I'm sure would be almost as fast as inline code (as it is, I have function calls to push and pop the return location on an internal stack object). C++ code available upon request.
|
Tue, 28 Sep 2004 01:53:27 GMT |
|
|