I've had that refuse to cooperate and crash problem.
You may have an extra control or two on the form you don't know about.
Check the Form properties window and see if there are any controls
listed you aren't using. Also, select any remaining frames and check for
duplicate controls on them. (or duplicate frames)
The RefEdit control can duplicate itself gratuitously and copies of other controls
can show up just by touching that Ctrl key sometimes.
If all fails...
(1) You could start over with a new form
(2) Use a work around by replacing the RefEdit with an InputBox.
My "Shade Data Rows" add-in on the Products page at my website
uses that technique. It has a picture of a RefEdit control that when clicked
shows an InputBox. Not for all occasions, but if you are really ****ed...
--
Jim Cone
San Francisco, USA
http://www.realezsites.com/bus/primitivesoftware
"Pflugs"
wrote in message
Thanks for the well wishes and the advice to avoid the marriage_Exit event!
That's pretty clever...
Anyway, the problem I've been having is that RefEdit code refuses to let me
step through it. It will crash even with breakpoints and stop commands. Any
event that even references the RefEdit seems to be susceptible to this
behavior, even Userform events. That makes it awfully hard to code and
debug!
I guess the best thing to do would be to write procedures called by command
buttons instead of events, but that assumes extra intelligence by the user.
Stupid controls...
Thanks,
Pflugs
"Jim Cone" wrote:
Well, getting married does seem to rid ones' mind of other issues. <g
Best of luck to you.
I know of no other Office controls that create problems similar to the
RefEdit control.
I have found that the interaction between code and controls is sometimes
not as I visualize it. It can be revealing to step thru the code one line at a time.
Oh, and it is best to avoid the marriage exit event. <g
--
Jim Cone
San Francisco, USA
http://www.realezsites.com/bus/primitivesoftware
"Pflugs"
wrote in message
I had not seen Jon's post since 6/30 was my wedding day. I apologize.
The two RefEdit controls were in frames. I have since removed the frames,
but I still had problems with the RefEdit events. I removed all set focus
commands relating to the RefEdits, and I'm trying to write other events
instead of a RefEdit_Change event.
Are there any problems with using Enter/Exit/Change events with other
controls, especially textboxes?
Thanks,
Pflugs
"Jim Cone" wrote:
Jon Peltier's advice/answer to your almost identical post of 06/27/2007
would be worth reading again.
I would add - never set the focus to a RefEdit control and
do not add a RefEdit control to a Frame.
--
Jim Cone
San Francisco, USA
http://www.realezsites.com/bus/primitivesoftware
"Pflugs"
wrote in message
I have been having issues using RefEdit controls and events, and I have
narrowed the problem down to how the user uses the control. That is, if
RefEdit1 has focus and the user clicks in the text box area of the control
and then selects cells in the background, everything is fine. All events
work correctly, and the userform works as planned.
However, if the user clicks on the RefEdit's button (the one with a
horizontal line that when clicked collapses the form), the user is allowed to
select cells and return to the form, but when the events attempt to run, the
userform crashes. Excel crashes soon thereafter.
I am using enter, exit, and change events with the RefEdit control. I have
tried cleaning the code with Rob Bovey's cleaner. Removing all RefEdit
events seemed to work, but the userform doesn't function as I want it to.
Does anyone have an explanation for this? Is there a way to limit the
RefEdit control to not allow users to click on the collapse button?
Thanks,
Pflugs