Field Zoom Replacement

[KitCaz]

In Access Shift-F2 will allow editing a field's contents in a separate window.

While this feature is useful in editing longer values (e.g., memo fields),
it's annoying in that it defaults to selecting all text and carriage returns
close the window. Users don't often know that Ctrl-Enter is required to
start a new line, etc., and the window can't be resized.

Has anyone developed any generic replacement coding for the Field Zoom /
Shift-F2 feature? Ideally, I could create my own form with font options and
OK/Cancel options, etc. but I'm not certain how I'd generically transfer
field values from any controls to/from such a form.

 

[Nikos Yannacopoulos]

It looks to me like the custom form replacement is indeed the way to go.
As for "communication" between the two:

* you can use the control's double-click event, for instance, to open
the custom zoom form, passing along the original form and control name
in the OpenArgs of the OpenForm command, like:

vCallerID = Me.Name & ";" & Me.ActiveControl.Name
DoCmd.OpenForm "frmZoom",,,,,,vCallerID
Forms("frmZoom").Controls("txtZoom") = Me.ActiveControl


* On the zoom form (frmZoom), the code behind the OK button could be
something like:

vSep = InStr(1,OpenArgs,";") 'separator position
vFrm = Left(OpenArgs, vSep - 1)
vCtrl = Right(OpenArgs, Len(OpenArgs) - vSep)
Forms(vFrm).Controls(vCtrl) = Me.txtZoom
DoCmd.Close acForm, Me.Name

(txtZoom is the unbound textbox on form frmZoom in which the entry is
edited).

HTH,
Nikos

 

[KitCaz]

This is great! One question:

I see the form wouldn't be launched as a dialog box/modal, and I guess
that's required in order to pass the calling form's current control value to
the new zoom form's text box txtZoom. My only fear is that my user will
click back on the calling form (thus hiding this new zoom form from view),
potentially relocating their cursor elsewhere, then finding the form again
(e.g. via the Windows menu choice) and clicking ok to update the wrong
control. What do you suggest to make sure this doesn't happen? Putting the
text into the OpenArgs too, as a 3rd piece? Or hiding the zoom form if it's
focus is lost (I recall that can be done but not sure how)?

 

[KitCaz]

Perhaps converting the line below such that it can exist in frmZoom's
form_load event? How would I re-write the "Me.ActiveControl" portion from
the OpenArg values?

Forms("frmZoom").Controls("txtZoom") = Me.ActiveControl

 

[Nikos Yannacopoulos]

Very good point! Though I haven't tried it, I guess I would use
frmZoom's On Open event, with a line code like:

vSep = InStr(1,OpenArgs,";") 'separator position
vFrm = Left(OpenArgs, vSep - 1)
vCtrl = Right(OpenArgs, Len(OpenArgs) - vSep)
Me.txtZoom = Forms(vFrm).Controls(vCtrl)

while also removing the last line of code in the original Double Click
code snipped, which was supposed to do the same.

HTH,
Nikos

 

[KitCaz]

Thanks again! Wanna advise me once more?

In addition to the nice suggestion to launch this zoom form with
Double_Click event, I want to also replace the traditional field zoom via the
key-press Shift-F2 too. I was thinking rather than trap for the key on all
of my forms I'd just reassign the keystroke via a macro. In order to do this
I would just then need to ensure the zoom form doesn't load if no other form
has focus or if the control which has focus isn't a relevant control when the
user presses Shift-F2 (e.g. while the Database window has focus). I guess I
could detect this in the On Open event, too, canceling it if my conditions
aren't met. How would I ensure my two conditions are met--that there is no
active form or relevant active control (e.g. text box)?

 

[Nikos Yannacopoulos]

Hmm... you got me there, I've never tried anything similar. Let's see:
To check if a form is open, you could use Forms.Count, which will return
0 if none is open.
If the previous check succeeds, you can check the control typeto see if
it is a textbox.
So, your checking code would be something like:

If Forms.Count = 0 Then
vFrm = Forms(ActiveForm).Name
vCtrl = Forms(vFrm).Controls(ActiveControl).Name
If Forms(vFrm).Controls(vCtrl).ControlType = acTextBox Then
vCallerID = vFrm & ";" & vCtrl
DoCmd.OpenForm "frmZoom",,,,,,vCallerID
End If
End If

HTH,
Nikos

 

[KitCaz]

Excellent, the control type check is just the thing. The form count is
probably a vulnerability because the user could have a form open but behind
some non-qualifying object like the database window or a report. But you
know what, I'll just let an error handler deal with it and just cancel out in
this case.

Nikos, you've been very helpful on this. I thank you very much! I've
learned a lot.

 

[Nikos Yannacopoulos]

Welcome!

You're right on the "form-behind-the-scenes" vulnerability. Actually one
would have to modify the code to handle switchboards or hidden forms, by
making sure that Forms(ActiveForm).Name <> "MySwitchboard" or
Forms(ActiveForm).Visible = True and Forms.Count > 1 if a hidden one
exists etc.
There's another flaw of this approach, I regret to say, which you
probably haven't thought of yet: it can't handle textboxes in subforms,
at least not as is. In theory it could be modified to check the
Me.Parent property (which would err if the active control is not
actually in a subform).

Regards,
Nikos

 

[KitCaz]

Nikos,

Thanks for all the time you've put in on this. You're right, the subform
thing is going to hose the entire concept, especially on the writing back of
the value.

Will OpenArgs accommodate passing the entire value into the form? Maybe I
can send it into the form this way. On the way out I guess I will have to
write to a globally available string variable (perhaps using this in both
directions).

What do you think?

I could consider checking for the me.parent property, but what would I do
when I had it? I still couldn't refer to the form collection to send my
string back, could I? Or would I have to change the logic to search for that
form as a subform control first?

 

[Nikos Yannacopoulos]

Nikos,

Thanks for all the time you've put in on this. You're right, the subform
thing is going to hose the entire concept, especially on the writing back of
the value. Correct.


Will OpenArgs accommodate passing the entire value into the form? Maybe I
can send it into the form this way.

I suppose so, as long as it's not too long.

On the way out I guess I will have to
write to a globally available string variable (perhaps using this in both
directions).

This could be a way to do it, although global variables are not very
popular among developers, for they have this nasty habit of resetting at
untrapped errors. What's more, this would solve the referencing problem,
but not the triggering part; how do you notify the original form that
the edited value is now availabble in the global variable, and can be
"read" into the orogonal textbox?

I could consider checking for the me.parent property, but what would I do
when I had it? I still couldn't refer to the form collection to send my
string back, could I?

The Me.Parent property was what I had in mind; actually I was thinking
of a loop checking it, starting from the textbox up, and exiting on
error (when there is no parent). I haven't tested it though.

Or would I have to change the logic to search for that
form as a subform control first?

Seems logical, I hadn't thought of that.

Pls do post back if you crack it!

Regards,
Nikos