show only browse

Kenneth Brody kenbrody at spamcop.net
Thu Sep 16 20:52:14 PDT 2010


On 9/16/2010 5:42 PM, Richard Kreiss wrote:
[...]
>>>> And is probably still more complex than you need.  Why don't you just
>>>> do everything in the @key9 processing?
>>>
>>> That does work - but only if I put a SHOW "@" before executing the
>>> switchto (sn).
>>
>> And what makes you think that you don't need something between the
>> "show=only" browse lookup and something that will take down the browse
>> window?
>
> Because pressing enter without the screen switch brings the browse down.  I
> have been playing with this for about 4 days now and at no time have I
> needed to issue a CLEARB to bring down the browse.

Let me re-quote your previous statement:

>>> That does work - but only if I put a SHOW "@" before executing the
>>> switchto (sn).


> I added similar code to a test file - no auto process and no @entsel.  In
> this file, the browse does stay up when<enter>  is pressed.

You've also eliminated your SWITCHTO.

> Added a second screen and found switching to that screen brings down the
> browse window.

Does your processing have something that switches screens via programming? 
Perhaps something like a SWITCHTO command?

> Added CLEARB after the browse command.  The browse opened and closed.  Added
> another SHOW "@" above the clearB and now it worked without having to issue
> another @key to clear the browse.

Because you are now waiting for something between putting the browse window 
up and taking it down.

> At this point, I don't want to figure out why the browse is clearing, the
> programming works in this instance.

It's clearing because you clear it.

> When I have more time, I will look at it to see why the browse is closing
> without a clearb.

Let me re-quote your previous statement:

 >>> That does work - but only if I put a SHOW "@" before executing the
 >>> switchto (sn).


> The must be something in either my auto processing or @entsel which is
> bringing down the browse window.

Let me re-quote your previous statement:

 >>> That does work - but only if I put a SHOW "@" before executing the
 >>> switchto (sn).


> Is what I am seeing a possible bug?

Yes, but not in filePro.

-- 
Kenneth Brody


More information about the Filepro-list mailing list