VB6: With...End With time bomb? 
Author Message
 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  
 VB6: With...End With time bomb?


Fri, 19 Jun 1992 00:00:00 GMT  
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 
 [ 15 post ] 

 Relevant Pages 

1. With...End With statement bombing out in For...Next statement

2. Time bomb a Word Document

3. Generate Dataset bombs every time...

4. Shareware time bomb?

5. Application bombs over time

6. Time bombs, hari-kiri-ware, et al

7. Time Bomb

8. Start Time / End Time Diff?

9. start date/time, end date/time problem

10. MAPI properties o start and end time of an appointment

11. Find start and end times of selection

12. Find start and end times of selection?

 

 
Powered by phpBB® Forum Software