Closing Lebans' clsMonthCal

  • Thread starter Thread starter Jack Leach
  • Start date Start date
J

Jack Leach

Hi, thanks in advance for any insight...


I'm trying to run Stephens Month Calendar from a standard module rather than
a form in an effort to globalize many redundant procedures behind my forms.
The function itself passes the control, and verifies that the user wants to
replace a date if there's already one picked. No biggie.

My question is how to go about making sure that the class closes correctly.
As setup per his instructions in a Form's module, the Load event sets the
private mc, and the Unload event checks the IsCalendar property of the class
and either closes or cancels the unload accordingly. I'm not quite sure how
to capture this from a standard module procedure (or if I should be screwing
with this at all really).

Here's a skeleton of the procedure:

Public Function SetDate(ctl As Control, lWnd As Long)
Dim mc As New clsMonthCal
mc.hWndForm = lWnd
...
...
blRet = ShowMonthCalendar(mc, dtStart, dtEnd)
...
...
Exit_Proc:
Set mc = Nothing
Exit Function
Error_Proc:
...
Resume Exit_Proc
End Function


The Set mc = Nothing line runs the Class_Terminate method of clsMonthCal,
which I assume is suffient to clean things up under normal circumstances
(there is no explicit closing of the class in the Form module setup other
than setting it Nothing in the Unload event).

Being that this class opens the calendar as system modal, I think the only
way to close the db without closing the calendar would be a power
interruption or task manager shutdown.

Any idea's on how I can trap the IsCalendar property and suspend the code if
it is true? Even in the original form module instructions, there doesn't
seem to be any method to handle things if IsCalendar is true... it just exits
the sub. Based on my experiment stepping through the code behind his class
(yes, it wall crash your machine), it seems that there's no way to get ANY
other code to run while that calendar is open.



So far everything seems to be working fine, with the exception of handling
this unclean closing... any ideas would be great.

Thanks!


--
Jack Leach
www.tristatemachine.com

"I haven't failed, I've found ten thousand ways that don't work."
-Thomas Edison (1847-1931)
 
I must warn you that I don't know that specific class. So my comments would
be generic.

About being enough to set an object-VARIABLE to nothing to close the object,
the answer is NO if you mean destroying the object. The object won't be
"destroyed" from memory if another variable to it is still alive and well.
In your case, there is a

ctl AS Control

in the function signature, so if have:

Set ctl = mc

somewhere, then even if the VARIABLE mc is set to nothing, the VARIABLE ctl
is not, and your OBJECT would still be alive and well even after mc
destroyed its own way to reach the object. Just like if Mary (mc) and
Claudia (ctl) have both your telephone number, but Mary, somehow upset by
you, destroyed all the documents she have where your telephone number
appears... that does still leave Claudia able to reach you through your
telephone number. If you prefer, mc and ctl are just 'way to reach the
object' in memory, not the whole memory allocated to the object. (That is
why it is sometimes helpful to remember that they are, in reality,
VARIABLES, not the OBJECT itself). Only if everyone having a way to reach
the object get out of scope, or destroy the reference to reach the object,
only then the object will be considered dead and the memory it occupies
would become available to some other uses. There is no need to explicitly
set an object-VARIABLE to nothing if the variable is about to get out of
scope, neither if you are about to assign it to something else: it is done
for you. If you do it that just doesn't hurt. If Mary destroy all her
documents where your telephone number appears, when the 'system' will try to
do the same, it will got... nothing as 'telephone number' to 'reach' and
check for definitive erasure from memory, since Mary won't have your real
phone number, anymore, to send to the 'system'! Same pattern if you set the
variable to Nothing before the system does it.


As far as having some other code running while a modal form is open, under
VBA, in general, onTimer events should still be firing, as well as some
other events (although I don't think to any other event, natively present
right out of the box, for Access Forms). So, somehow the modal form changes
an Access global variable, with maybe a DoEvents just after that to help on
responsiveness, and a Timer, on another open form, pooling the Access global
variable, ***may*** be a possible solution, in VBA, to get some of your code
being aware of a modification performed by your modal form. Another one,
more complex, would be to let the modal form raising some event on one of
your variable-object, or simply to run a procedure supplied by one of your
object (may become weird, though, with possible re-entrance problems, so I
would not recommand this approach). You probably already know that to end
the modality-wait of a form your code can turn it invisible! Doing so, the
VBA code which was blocked by the form-modality-wait resumes its execution
where it opens the modal form.



Hoping it makes sense,

Vanderghast, Access MVP
 
Thanks, this gives me something to think on. For the record, the ctl passed
to the function is not related to the class in any way, but I understand your
description if it were.

I hadn't considered a timer event being a way that something may happen
while the calendar is open.

--
Jack Leach
www.tristatemachine.com

"I haven't failed, I've found ten thousand ways that don't work."
-Thomas Edison (1847-1931)
 
Back
Top