 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
MS Access Forum / Forms Programming / May 2005Field Zoom Replacement
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. 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 > In Access Shift-F2 will allow editing a field's contents in a separate window. > [quoted text clipped - 7 lines] > OK/Cancel options, etc. but I'm not certain how I'd generically transfer > field values from any controls to/from such a form. 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)? > It looks to me like the custom form replacement is indeed the way to go. > As for "communication" between the two: [quoted text clipped - 33 lines] > > OK/Cancel options, etc. but I'm not certain how I'd generically transfer > > field values from any controls to/from such a form. 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 > This is great! One question: > [quoted text clipped - 45 lines] > > > OK/Cancel options, etc. but I'm not certain how I'd generically transfer > > > field values from any controls to/from such a form. 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 > 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 [quoted text clipped - 51 lines] >>>>OK/Cancel options, etc. but I'm not certain how I'd generically transfer >>>>field values from any controls to/from such a form. 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)? > Very good point! Though I haven't tried it, I guess I would use > frmZoom's On Open event, with a line code like: [quoted text clipped - 65 lines] > >>>>OK/Cancel options, etc. but I'm not certain how I'd generically transfer > >>>>field values from any controls to/from such a form. 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 > Thanks again! Wanna advise me once more? > [quoted text clipped - 78 lines] >>>>>>OK/Cancel options, etc. but I'm not certain how I'd generically transfer >>>>>>field values from any controls to/from such a form. 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. > 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 [quoted text clipped - 97 lines] > >>>>>>OK/Cancel options, etc. but I'm not certain how I'd generically transfer > >>>>>>field values from any controls to/from such a form. 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 > 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 [quoted text clipped - 106 lines] >>>>>>>>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, 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? > Welcome! > [quoted text clipped - 122 lines] > >>>>>>>>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, > > 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 |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.