inserting text at mouse position

[Ron Weiner]

Gina

Marsh is correct you should fix the Dim, but it is not the reason for the
problem.

Also I notice that you routinely use code like

Set rs = CurrentDb.OpenRecordset(strSQL)

but rarely use code like
rs.Close
Set rs = Nothing

You should really get in the habit of closing and destroying all of the
objects you open and create. One of these days this sloppy coding practice
will come around and bite you where it really hurts.

Ron W

Thanks Marsh,

I will gratefully look at all suggested aspects ....
wel I didn't know that the dim could be a reason ...

Gina

maybe I should mention I work with access 2k - but I don't know anything
else apart from a BUG ... iiiiii ...
setting a halt on each of the evnets they get called and values assigned
Thans so much for your time and good advice ....
well how do I decomile the code ??

for completion here's the rest of relevant code: []
In Module ErrorChecking :
Dim mlngSelStart, mlngSelLen As Long

[]


Gina, I don't really have anything to add to Ron's excellent
suggestions, but I did notice the above Dim statement might
cause problems under some odd circumstances. I think it
should be:

Dim mlngSelStart As Long, mlngSelLen As Long

I don't use A2k, so this may be irrelevant, but make sure
that you have turned off the NameAutoCorrect feature.

If corruption has crept into your app, you may want to look
at:
http://www.granite.ab.ca/access/corruptmdbs.htm
http://www.granite.ab.ca/access/decompile.htm

 

[Gina]

Ron,
yes you are right ..... I will check through and fix that stuff ....
I already fixed what Marsh sugested ....the Dim thing
I try to avoid having 'corrupted' things created myself

Thanks again so much... I will sleep well tonight )
it's such a relief that you competent guys willing to help are around here
in this forum!!!

Gina

Gina

Marsh is correct you should fix the Dim, but it is not the reason for the
problem.

Also I notice that you routinely use code like

Set rs = CurrentDb.OpenRecordset(strSQL)

but rarely use code like
rs.Close
Set rs = Nothing

You should really get in the habit of closing and destroying all of the
objects you open and create. One of these days this sloppy coding practice
will come around and bite you where it really hurts.

Ron W

Thanks Marsh,

I will gratefully look at all suggested aspects ....
wel I didn't know that the dim could be a reason ...

Gina

Gina wrote:
maybe I should mention I work with access 2k - but I don't know anything
else apart from a BUG ... iiiiii ...
setting a halt on each of the evnets they get called and values assigned
Thans so much for your time and good advice ....
well how do I decomile the code ??

for completion here's the rest of relevant code:
[]
In Module ErrorChecking :
Dim mlngSelStart, mlngSelLen As Long
[]


Gina, I don't really have anything to add to Ron's excellent
suggestions, but I did notice the above Dim statement might
cause problems under some odd circumstances. I think it
should be:

Dim mlngSelStart As Long, mlngSelLen As Long

I don't use A2k, so this may be irrelevant, but make sure
that you have turned off the NameAutoCorrect feature.

If corruption has crept into your app, you may want to look
at:
http://www.granite.ab.ca/access/corruptmdbs.htm
http://www.granite.ab.ca/access/decompile.htm

 

[Marshall Barton]

I tried it in AXP and got the same result. I didn't even
specify a RowSource for the combo box, just used it as if it
were a text box. I also changed the combo box to a text box
and still got the message. What's more, if I used the Enter
key to move out of the combo/text box, a new line was added
to the memo field along with the other text!?

This is strange, I have done this kind of thing several
times before using A97 and a text box instead of a combo box
and never run into a problem, but I may have used different
events(?)

Instead of using error handling to ignore the message, I
tried using the combo box's Exit event and it worked fine.
Not quite the same as the AfterUpdate event, but it might be
acceptable in most cases.

 

[Ron Weiner]

Marsh

I'm thinking that the Exit event probably doesn't make much sense as far as
the interface goes. Typically combo boxes do what ever they do when that
user selects an item from the list not when they move the focus to another
control.

In any case I'm thinking this is a Bug in Access. As an MVP do you have any
way to report this to MSoft to get their take on this behavior.

Ron W
www.WorksRite.com

I tried it in AXP and got the same result. I didn't even
specify a RowSource for the combo box, just used it as if it
were a text box. I also changed the combo box to a text box
and still got the message. What's more, if I used the Enter
key to move out of the combo/text box, a new line was added
to the memo field along with the other text!?

This is strange, I have done this kind of thing several
times before using A97 and a text box instead of a combo box
and never run into a problem, but I may have used different
events(?)

Instead of using error handling to ignore the message, I
tried using the combo box's Exit event and it worked fine.
Not quite the same as the AfterUpdate event, but it might be
acceptable in most cases.
--
Marsh
MVP [MS Access]

Well this has been fun, NOT! :-(

This is either a bug in Access 2K or a lack of understanding on my part. I
invite others to have a look at this. Here are instructions to recreate the
problem. Create a new form bound to a table that has a memo field. Add a
text box (its name will default to Text0) and bind it to the memo field in
the table. Add a Combo box (its name will default to Combo2) that is
unbound and has a row source like "Select Foo from Bar". Just one column
nothing fancy!

Add the following code:

Option Compare Database
Option Explicit
Dim mlngSelStart As Long, mlngSelLen As Long

Private Sub Combo2_AfterUpdate()
Text0.SetFocus
Text0.SelStart = mlngSelStart
Text0.SelLength = mlngSelLen
Text0.SelText = Combo2
End Sub

Private Sub Text0_LostFocus()
mlngSelStart = Text0.SelStart
mlngSelLen = Text0.SelLength
End Sub

Select an item from the Combo -- KA-Boom 2115 error "The macro or function
set to the Before Update or Validation rule property for the field is
preventing Microsoft Access form saving the data in the field."

The cool part of all this is that the Data has already been inserted into
the text box! So the work around is to add an error handler that will
ignore the error (On Error Resume Next) to the sub just before the line
(Text0.SelText = Combo2) that creates the error. If you had an existing
error handler in the sub you could add some code to the error handler like:

if err.number = 2115 then
resume next
else
' what ever the error handler is currently doing here
endif

Soooo..... Gina the specific answer to your dilemma is:

Me.txtArbeitsBeschreibung.SetFocus
Me.txtArbeitsBeschreibung.SelStart = ErrorChecking.GetmlngSelStart
Me.txtArbeitsBeschreibung.SelLength = ErrorChecking.GetmlngSelLen
On Error Resume Next
Me.txtArbeitsBeschreibung.SelText = cboText ' ******
On Error GoTo 0

However I have discovered that this error only happens with the AfterUpdate
and Click events of a Combo box. If you move the code to the Combo box
DoubleClick event there is NO ERROR generated. I do not know why.

Perhaps one the Msoft MVP's will take a whack at this. But for right now it
looks like a bug to me. I am using Access 2K 9.0.6926 SP-3

 

[Marshall Barton]

It sure looks like a bug to mee too, but I will defer to the
designer on what is supposed to happen (even if I can't
imagine why anyone would want this behavior).

I put it in the pipeline, but who knows what they will or
will not do about it.

 

[Marshall Barton]

I've dug around and found some old code that I used in the
past. It reminded me that there are additional issues
beyond the ones we've been discussing here. To avoid all
but one of them, I had used a command button to copy the
combo box's value to the memo text box.

The main additional issue is that if the text in the memo
text box is edited before the user indicates where the
Selxxx properties should be, then the text box's LostFocus
event procedure will set SelStart and SelLength to 0. You
can pick up the correct values in the BeforeUpdate event,
but you need a flag variable to tell the LostFocus procedure
to not save the 0s.

 

[Ron Weiner]

I have been using this kind of code for a couple of years BUT from a Modal
form that pops up when the user hits F5 in the Memo box. We call the form
the "Phrase Picker" and it is data driven to supply user pre-defined phrases
for the specific field it was invoked from. It allows the user to select
one or more phrases and the format to be used when pasting the phrases
(Bullet, Comma, Paragraph, etc.) . It places the text into the field it was
invoked from at the cursor point when the "Phrase Picker" form is closed. I
suppose that because we used a different from to do that phrase selection we
never ran into any of these kind of problems.

Then one fine day the users discovered that they could define phrases that
were up 40K in length (essentially complete documents) and we started
receiving reports that they were getting error's with the "Phrase Picker".
We discovered (to our total amazement) that they had defined these monster
phrases to save time completing the documents. We solved the problem by
parsing the phrases into 2K chunks with code similar to that I posted on the
26th. We haven't had a problem since.

While I am writing code I often think back to the "Phrase Picker" BUG, where
we expected the users to store away essentially sentence sized phrases, and
reflect on the line that Jeff Goldblum (Dr. Ian Malcolm) used in Jurassic
Park "Life Always Finds A Way".

Ron W

I've dug around and found some old code that I used in the
past. It reminded me that there are additional issues
beyond the ones we've been discussing here. To avoid all
but one of them, I had used a command button to copy the
combo box's value to the memo text box.

The main additional issue is that if the text in the memo
text box is edited before the user indicates where the
Selxxx properties should be, then the text box's LostFocus
event procedure will set SelStart and SelLength to 0. You
can pick up the correct values in the BeforeUpdate event,
but you need a flag variable to tell the LostFocus procedure
to not save the 0s.
--
Marsh
MVP [MS Access]

I'm thinking that the Exit event probably doesn't make much sense as far as
the interface goes. Typically combo boxes do what ever they do when that
user selects an item from the list not when they move the focus to another
control.

In any case I'm thinking this is a Bug in Access. As an MVP do you have any
way to report this to MSoft to get their take on this behavior.


"Marshall Barton" wrote. part.
I recreate
the Add
a field
in now
it

 

[Marshall Barton]

I have been using this kind of code for a couple of years BUT from a Modal
form that pops up when the user hits F5 in the Memo box. We call the form
the "Phrase Picker" and it is data driven to supply user pre-defined phrases
for the specific field it was invoked from. It allows the user to select
one or more phrases and the format to be used when pasting the phrases
(Bullet, Comma, Paragraph, etc.) . It places the text into the field it was
invoked from at the cursor point when the "Phrase Picker" form is closed. I
suppose that because we used a different from to do that phrase selection we
never ran into any of these kind of problems.

Then one fine day the users discovered that they could define phrases that
were up 40K in length (essentially complete documents) and we started
receiving reports that they were getting error's with the "Phrase Picker".
We discovered (to our total amazement) that they had defined these monster
phrases to save time completing the documents. We solved the problem by
parsing the phrases into 2K chunks with code similar to that I posted on the
26th. We haven't had a problem since.

While I am writing code I often think back to the "Phrase Picker" BUG, where
we expected the users to store away essentially sentence sized phrases, and
reflect on the line that Jeff Goldblum (Dr. Ian Malcolm) used in Jurassic
Park "Life Always Finds A Way".

Right! Users are very inventive in their use of our
applications ;-)

That line in Jurassic Park has stuck in my mind too. I
often use it to help explain why genetically modified,
insect resistent plants will just create tougher insects.

Until we understand that that line is a fundamental law of
life, we will always suffer from "unintended consequences".
I had just such a conversation last week about the fishing
industry being required to throw back all fish below a
certain size and how all that accomplished was that fish
only grow to the smaller size. Doublely troubling is that
fish that mature at the smaller size have fewer offspring.

It seems like the more we try to constrain users toward our
expectations of "good practices", the more users will evolve
their activities in unexpected and troublesome ways. :-\