In , on 11/10/2008
at 03:30 PM, Jim Moe said:

Hi,

> By adding a DosSleep(1) between the inserts and query I resolved the
>timing issue but it seems like a very weak solution.

Your problem sort of makes sense. I have to suspect that PM is doing much
of the container update processing in a worker thread. Even though you
are using WinSendMsg, there's nothing to guarantee that the screen update
is complete when the call returns.

Are you sure that the query is not failing?

> Is there a way to determine when a window update is complete?

Not to my knowledge. You could check the CNRINFO.cRecords, but it would
not surprise me if this count is updated long before the window repaint
completes.

Are you sure that the CM_QUERYRECORDRECT return was bogus, or just not the
final value. It's not unusual for an individual record's position to
change multiple times during a large container update.

In the general case there's no way to know if a container update is done.
There might be unprocessed messages in the queue.

Without really knowing why you are using CM_QUERYRCORDRECT when you are,
it occurs to me that perhaps whatever you are doing should be done in the
CN_EMPHASIS handler.

Steven

--
--------------------------------------------------------------------------------------------
Steven Levine MR2/ICE 3.00.11.18 BETA #10183
eCS/Warp/DIY/14.103a_W4 www.scoug.com irc.ca.webbnet.info #scoug (Wed 7pm PST)
--------------------------------------------------------------------------------------------

On 11/10/08 10:35 pm, Steven Levine wrote:
>
>> By adding a DosSleep(1) between the inserts and query I resolved the
>>timing issue but it seems like a very weak solution.
>
> Are you sure that the CM_QUERYRECORDRECT return was bogus, or just not the
> final value. It's not unusual for an individual record's position to
> change multiple times during a large container update.
>
The coordinate values were always the same meaningless values. I got the
idea of a delay because inserting extra logging or pause-for-the-cause
dialogs returned correct values. And no error values were returned in any
case; the bogus and correct returns both claimed the function executed
properly.

> In the general case there's no way to know if a container update is done.
> There might be unprocessed messages in the queue.
>
Bugger.

> Without really knowing why you are using CM_QUERYRECORDRECT when you are,
> it occurs to me that perhaps whatever you are doing should be done in the
> CN_EMPHASIS handler.
>
A set of messages is maintained separate from the window. Part of the
data is the RECORDCORE structure. When a folder is selected for viewing,
the set is scanned for selected records; the first selected (CRA_SELECTED)
item is remembered. After sending the CM_INSERTRECORDARRAY, the remembered
record is queried for its position so the container can be scrolled to
bring it into view.
I vaguely recall trying to do the same in CN_EMPHASIS with a similar
result of getting bad position data.

--
jmm (hyphen) list (at) sohnen-moe (dot) com
(Remove .AXSPAMGN for email)