[AccessD] Destroying form object causes Access 2013 to crash?

[Bryan Carbonnell]

Make sure you send it offlist. It won't make it through to the list.

Your friendly neighbourhood Listmaster,
Bryan

On 7 January 2017 at 17:04, Ryan Wehler <wrwehler at gmail.com> wrote:
> Do you want the whole accdb?
>
> Sent from my iPhone
>
>> On Jan 7, 2017, at 6:01 PM, John Colby <jwcolby at gmail.com> wrote:
>>
>> I'll look at it tonight. Can you email me your code?
>>
>>> On Jan 7, 2017 15:30, "Ryan W" <wrwehler at gmail.com> wrote:
>>>
>>> I revise my statement.  It seems to be something in the Control Scanner
>>> (or the Text or Cbo Class) doing it.  If I comment out the entire control
>>> scanner I can close the form crash free.
>>>
>>> I just copy and pasted those classes from John’s posts and everything
>>> compiles okay.. Not sure what changed as the classes ‘work’ when in the
>>> form but something about the scanner or the class instantiation causes the
>>> crash on close.
>>>
>>> One thing I do notice is that the clsTxt and clsCbo classes do not ever
>>> empty (‘nothing’) the objects.  I assume (probably wrongfully?) that when
>>> you set mfrm = nothing it also destroys the class objects that it created?
>>>
>>>
>>>
>>> --
>>> AccessD mailing list
>>> AccessD at databaseadvisors.com
>>> http://databaseadvisors.com/mailman/listinfo/accessd
>>> Website: http://www.databaseadvisors.com
>>>
>> --
>> AccessD mailing list
>> AccessD at databaseadvisors.com
>> http://databaseadvisors.com/mailman/listinfo/accessd
>> Website: http://www.databaseadvisors.com
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com



-- 
Bryan Carbonnell - carbonnb at gmail.com
Life's journey is not to arrive at the grave safely in a
well-preserved body, but rather to skid in sideways, totally worn out,
shouting "What a great ride!"