Prev: can I make access remember a last unbound number
Next: two linked subforms on an unbound main form
From: Dirk Goldgar on 8 Dec 2009 16:39
"Banana" <Banana(a)Republic> wrote in message
news:4B1EC1F3.7050400(a)Republic...
>
> Ah, I see. Thinking about it bit, it does makes sense- Echo disables the
> screen updating but we're replicating the UI functionality which of course
> works through the screen (more or less).

Yes, that's the conclusion I came to. I was surprised to find that, even if
I turned Echo back on before SelectObject and RunCommand acCmdSelectAll, it
still didn't work.

> I tried something and this seems to work here:
>
> Sub EditQueryClearSQL(strQuery As String)
> On Error Resume Next
> Echo False
> DoCmd.OpenQuery strQuery, acViewDesign
> DoCmd.RunCommand acCmdSQLView
> DoCmd.RunCommand acCmdDelete
> Echo True
> End Sub
>
>
> Basically, I removed the RunCommand selecting the object & text because by
> default, Access already has the SQL highlighted when you open it in SQL
> View so we can just go directly to acCmdDelete.

Yes, that was the first thing I did, but I hoped that by explicitly
selecting the query and doing a "select all", one might avoid any quirks as
much as possible. I don't know how much faith to put in that hope, though.

It occurs to me that one might use Windows API calls to locate the query
design window and send a message to clear it. I don't feel like spending
the time to work that out right now, though.

--
Dirk Goldgar, MS Access MVP
Access tips: www.datagnostics.com/tips.html

(please reply to the newsgroup)

From: Banana on 8 Dec 2009 20:10
Dirk Goldgar wrote:
> Yes, that's the conclusion I came to. I was surprised to find that, even if I turned Echo back on before SelectObject and RunCommand acCmdSelectAll, it still didn't work.

I didn't expect that particular error. Quite surprising, indeed!

> Yes, that was the first thing I did, but I hoped that by explicitly
> selecting the query and doing a "select all", one might avoid any quirks
> as much as possible. I don't know how much faith to put in that hope,
> though.

Perfectly reasonable.

> It occurs to me that one might use Windows API calls to locate the query
> design window and send a message to clear it. I don't feel like
> spending the time to work that out right now, though.

I'm also not sure if it's going to be any less fragile than the other
solutions we discussed. I've been never quite comfortable with that kind
of use for the APIs, and Vista & Win7 has changed considerably such
that SendMessage no longer work in the same manner.

I would imagine that if we were going down the API route, I'd want to
find if it was possible to temporarily disable mouse clicks during the
code is running. That's brute-force but at least not as fragile and in
theory the code should run quickly enough that user never notice.

From: Dirk Goldgar on 8 Dec 2009 21:34
"Banana" <Banana(a)Republic> wrote in message
news:4B1EF8F6.4030009(a)Republic...
>
> I'm also not sure if it's going to be any less fragile than the other
> solutions we discussed. I've been never quite comfortable with that kind
> of use for the APIs, and Vista & Win7 has changed considerably such that
> SendMessage no longer work in the same manner.

I didn't know that. <sigh> And I'd finally started to feel like I
understood the API.

> I would imagine that if we were going down the API route, I'd want to find
> if it was possible to temporarily disable mouse clicks during the code is
> running. That's brute-force but at least not as fragile and in theory the
> code should run quickly enough that user never notice.

That's an interesting idea. I doubt I'll go any farther with this, but I'll
hang onto it for future reference. Thanks.

--
Dirk Goldgar, MS Access MVP
Access tips: www.datagnostics.com/tips.html

(please reply to the newsgroup)

From: Marshall Barton on 8 Dec 2009 21:54
Banana wrote:
>I would imagine that if we were going down the API route, I'd want to
>find if it was possible to temporarily disable mouse clicks during the
>code is running. That's brute-force but at least not as fragile and in
>theory the code should run quickly enough that user never notice.


Don't forget about Timer events doing the same kinds of
things. That's my primary reason for avoiding RunCommand
and DoCmd without an object argument.

--
Marsh
MVP [MS Access]
From: Banana on 8 Dec 2009 22:39
Marshall Barton wrote:
> Don't forget about Timer events doing the same kinds of
> things.

Well, I could be wrong but a while ago, I did look at using Timer events
to run some code asynchronous and after some experimentation came to the
conclusion that Timer event does not run in a separate thread from the
rest of code so we would probably have a race condition but not
conflicts due to two pieces of code executing concurrently.

If we only have to worry about race condition, it shouldn't be material
as the code being discussed should enable mouse clicking/screen
updating/whatever before it finish and switch to the other procedure
waiting to be executed.

> That's my primary reason for avoiding RunCommand
> and DoCmd without an object argument.

I'm so there with you. I like to avoid either because I find it more
reliable to manipulate the objects directly. In this case, though, I
don't think there's any alternative.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: can I make access remember a last unbound number
Next: two linked subforms on an unbound main form