Hi Alaska Team,

there are bugs with refreshing and positioting in XbpBrowse.
In attached example you can see the wrong/unwanted behaviors.

Hope, this ready-to-use example will help you quickly solve problem,
because this is very frustating not only for me, but especially for my 
customors!

1. start program
2. go to record "Audi - A4"
3. press D key
    - record will be deleted and oBrowse refreshed and correctly positioned
    (current record is "Audi K70 White" now)
4. press R key (here with this I simulate "changing" value(-es) in some 
called function or from other workstiations in real scenario)
    - record value was changed and oBrowse refreshed and correctly
positioned
    (current record is "Audi K70 Red" now, record before is "VW Van Racing
Green", record after is "Audi GL Soft Blue")
5. close window


6. go to record "Audi - K70" (scope White is active)
7. press D key
    - record will be deleted and oBrowse refreshed and correctly positioned
    (current record is "Bugatti - Overdrive" now)
8. press R key
    - record value was changed and oBrowse refreshed, but NOT correctly 
positioned
      Record pointer is moved to the top!!!
      It must be set to next or previous first visible record like "delete 
variant" does!!!

9. close window


10. go to record "Mercedes - Four Doors"  (scope White+M is active)
11. press D key
    - record will be deleted and oBrowse refreshed and correctly positioned
    (current record is "Mercedes - Injection" now)
12. press R key
    - record value was changed and oBrowse refreshed, but NOT correctly 
positioned
      Record pointer is moved to the top!!!
      It must be set to next or previous first visible record like "delete 
variant" does!!!
    (current record is "Mercedes - Injection" now)
11. press D key
    - record will be deleted and oBrowse refreshed and correctly positioned
    (current record is "Mercedes - JLXl" now)
12. press D key
    - record will be deleted and oBrowse NOT refreshed correctly!!!
    ("current" record is "Nissan - Van" now)!!! this is NOT true!!!
13. press D key
    - "previous current" record will be deleted and oBrowse refreshed 
correctly...!!!
14. close window


14. go to record "Toyota - Quattro"
15. press D key
    - record will be deleted and oBrowse refreshed and correctly positioned
    (current record is "Suzuki - Station Wagon" now)
16. go to previous record "Rover - R4"
17. press R key
    - record value was changed and oBrowse refreshed, but NOT correctly 
positioned
      Record pointer is moved to the top!!!
      It must be set to next or previous first visible record like "delete 
variant" does!!!
18. ... NN  just now in any order press D key on any record from top or 
bottom or from centre of dbf...
      but be careful watching when you will be deleting LAST visible 
record!!!
      after deleting it any "new one visible record" will be "visible" 
again..
NN+1. close window


Is available any "quick" workaround or other solution or HotFix?

TIA & Regards

                Zdeno 

Hi,

Did you send your sample to support@alaska-software.com? I think that is the
fastest way.

Regards,
Chris Andries.


<Zdenko Bielik> wrote in message
news:9a04c76$7ce0b826$865@news.alaska-software.com...
> Hi Alaska Team,
>
> there are bugs with refreshing and positioting in XbpBrowse.
> In attached example you can see the wrong/unwanted behaviors.
>
> Hope, this ready-to-use example will help you quickly solve problem,
> because this is very frustating not only for me, but especially for my
> customors!
>
> 1. start program
> 2. go to record "Audi - A4"
> 3. press D key
>     - record will be deleted and oBrowse refreshed and correctly
positioned
>     (current record is "Audi K70 White" now)
> 4. press R key (here with this I simulate "changing" value(-es) in some
> called function or from other workstiations in real scenario)
>     - record value was changed and oBrowse refreshed and correctly
> positioned
>     (current record is "Audi K70 Red" now, record before is "VW Van Racing
> Green", record after is "Audi GL Soft Blue")
> 5. close window
>
>
> 6. go to record "Audi - K70" (scope White is active)
> 7. press D key
>     - record will be deleted and oBrowse refreshed and correctly
positioned
>     (current record is "Bugatti - Overdrive" now)
> 8. press R key
>     - record value was changed and oBrowse refreshed, but NOT correctly
> positioned
>       Record pointer is moved to the top!!!
>       It must be set to next or previous first visible record like "delete
> variant" does!!!
>
> 9. close window
>
>
> 10. go to record "Mercedes - Four Doors"  (scope White+M is active)
> 11. press D key
>     - record will be deleted and oBrowse refreshed and correctly
positioned
>     (current record is "Mercedes - Injection" now)
> 12. press R key
>     - record value was changed and oBrowse refreshed, but NOT correctly
> positioned
>       Record pointer is moved to the top!!!
>       It must be set to next or previous first visible record like "delete
> variant" does!!!
>     (current record is "Mercedes - Injection" now)
> 11. press D key
>     - record will be deleted and oBrowse refreshed and correctly
positioned
>     (current record is "Mercedes - JLXl" now)
> 12. press D key
>     - record will be deleted and oBrowse NOT refreshed correctly!!!
>     ("current" record is "Nissan - Van" now)!!! this is NOT true!!!
> 13. press D key
>     - "previous current" record will be deleted and oBrowse refreshed
> correctly...!!!
> 14. close window
>
>
> 14. go to record "Toyota - Quattro"
> 15. press D key
>     - record will be deleted and oBrowse refreshed and correctly
positioned
>     (current record is "Suzuki - Station Wagon" now)
> 16. go to previous record "Rover - R4"
> 17. press R key
>     - record value was changed and oBrowse refreshed, but NOT correctly
> positioned
>       Record pointer is moved to the top!!!
>       It must be set to next or previous first visible record like "delete
> variant" does!!!
> 18. ... NN  just now in any order press D key on any record from top or
> bottom or from centre of dbf...
>       but be careful watching when you will be deleting LAST visible
> record!!!
>       after deleting it any "new one visible record" will be "visible"
> again..
> NN+1. close window
>
>
> Is available any "quick" workaround or other solution or HotFix?
>
> TIA & Regards
>
>                 Zdeno
>
>
>

> Did you send your sample to support@alaska-software.com?

Hi Chris,

just done, thanks 

           Zdeno

Zdeno,

The things you encounter aren't really bugs of the XbpBrowse() class and 
are probably not even errors! What you see is (mostly) standard Clipper 
database navigational functionality!

What you want is to manipulate the record pointer to behave a specific 
way, which is not the default behavior, though. But you can easily do 
this yourself in your code.

For example, neither the "DbDelete()" nor the "Color := 'Red'" will 
result in a change of record pointer, unless you have a scope or filter
active -- "Set Deleted On" is a type of scope -- so you need to manually 
reposition the record pointer to the next (or last) visible record by 
yourself. One way to do refresh the record pointer is to use "DbSkip(0)".

On the other hand, you want a different behavior if a Scope and/or Filter 
is active than when it is not. For example, if you delete the first record
(under 3.), you want it to disappear and the record pointer moved to the 
next record (in the current sort order). On the other hand, when you 
change the color to "Red" (under 4.), you want the record pointer to stay
but the sort order changed and the relative position updated. This works
automatically like you expect, but only without any additional Scopes and 
Filters.

And if you introduce Scopes and Filters, you want the behavior to change!
When you change the color (under 8.) you want the record pointer to change
to the (previously) next logical record, even though the current record is 
no longer within the scope after the change, and the next logical record
at this point is the BoF() of the Scope -- the first record visible in the
browse table, while the (after-the-change) record pointer will be "EoF()"
or the "Ghost Record". The same problem is responsible for all the other 
issues that you see.

What you need to do, is to determine -- before you make a change -- which 
record you want to be the current record after the change. And you need 
to distinguish between changes that remove the current record from the 
Scope/Filter and ones which do not, as you don't want the record pointer 
to change in that case. You also need to accommodate the case were no 
record is in the Scope/Filter, in which case you want to be on the "Ghost 
Record" or "EoF()" and you don't want to allow any changes anymore!

Here is a small example, which fixes all of the issues that you mentioned.
And if there are others, you can probably make the necessary adjustments!

Procedure AlaskaBrowse()
[...]
LOCAL nCurPos := 0
LOCAL nNewPos := 0
[...]
if     (mp1 == Asc('d') .or. mp1 == Asc('D')    Delete Record
   if .not. EoF()
      nCurPos := RecNo()
      nNewPos := GetNewRecordPointer(oBrowse, nCurPos)
      DbDelete()
      ShowNewRecord(oBrowse, nCurPos, nNewPos)
   endif
elseif (mp1 == Asc('r') .or. mp1 == Asc('R')    Change to "Red"
   if .not. EoF()
      nCurPos := RecNo()
      nNewPos := GetNewRecordPointer(oBrowse, nCurPos)
      CARS->COLOR := 'Red'
      ShowNewRecord(oBrowse, nCurPos, nNewPos)
   endif
elseif (mp1 == Asc('w') .or. mp1 == Asc('W')    Change to "White"
[...]
return

Function GetNewRecordPointer(oBrowse, nCurPos)
LOCAL nNewPos := 0
   DbSkip(1)
   if EoF()
      DbGoBottom()
      if RecNo() == nCurPos
         DbSkip(-1) ; oBrowse:RowPos := max(1, oBrowse:RowPos - 1)
      endif
   endif
   nNewPos := RecNo() ; DbGoto(nCurPos)
return (nNewPos)

Procedure ShowNewRecord(oBrowse, nCurPos, nNewPos)
   DbSkip(0)
   if RecNo() # nCurPos
      DbGoto(nNewPos) ; DbSkip(0)
   endif
   oBrowse:RefreshAll()
return

Hope that helps,

-- Andreas

---                                                                      ---
  Andreas Gehrs-Pahl              E-Mail: GPahl@CharterMI.net
  415 Gute Street                     or: Andreas@DDPSoftware.com
  Owosso, MI 48867-4410               or: Andreas@Aerospace-History.net
  Tel: (989) 723-9927           Web Site: http://www.Aerospace-History.net
---                                                                      ---

Hi Andreas,

thanks for your info and workaround - really much appreciated.
Yes, I do it right now in "similar" way,
I call my function FindNewRecord() before deleting or changing value,
but I think, it is MUST be managed by Alaska!
If it works when no Scope or no Filter is set, it must work in same way in 
ALL other/next variants!
This my (or your) "workaround" was many-time consuming thing before I find 
right/truly reason for non-correct record positiong...

Anyway, I still think, navigation MUST be same in ALL scenarios and if this 
will be fixed or set default by Alaska, it will save many time and nerves 
for many programers and users!

Thanks again for code, I will check it and compare with my function!

            Zdeno



**********************
Function FindNewRecord( _cAlias )
**********************

Local nRecNo    := ( _cAlias )->( RecNo() )
Local nRecNoNew := 0

* step 1 - try find next visible record with moving forward / to Eof()
( _cAlias )->( dbSkip() )
Do While ( _cAlias )->( ! Eof() )
   If ! ( _cAlias )->( Deleted() )
      nRecNoNew := ( _cAlias )->( RecNo() )
      Exit
   Else
      ( _cAlias )->( dbSkip() )
*       nRecNoNew := ( _cAlias )->( RecNo() )
   EndIf
EndDo
* dcdebug 'a', nRecNo, nRecNoNew
* step 2 - if not found forward, try find next visible record moving back / 
to Bof()
If ( nRecNoNew == 0 )
   ( _cAlias )->( dbGoTo( nRecNo ) )   && go back to original record
   ( _cAlias )->( dbSkip( -1 ) )
   *
   Do While ( _cAlias )->( ! Bof() )
      If ! ( _cAlias )->( Deleted() )
         nRecNoNew := ( _cAlias )->( RecNo() )
         Exit
      Else
         ( _cAlias )->( dbSkip( -1 ) )
      EndIf
   EndDo
EndIf
* dcdebug 'b', nRecNo, nRecNoNew

If ( nRecNoNew == 0 )           && no visible record available...
   ( _cAlias )->( dbGoTop()    )
   nRecNoNew := ( _cAlias )->( RecNo() )
EndIf

( _cAlias )->( dbGoTo( nRecNo ) )

Return ( nRecNoNew )

*

Zdeno,

>thanks for your info and workaround - really much appreciated.

You are welcome, but it isn't a workaround -- it's what you need to do!

>Yes, I do it right now in "similar" way,
>I call my function FindNewRecord() before deleting or changing value,
>but I think, it is MUST be managed by Alaska!

That isn't really possible, as the Browse table doesn't delete or change
any records, so how can it do what you want? The Browse table simply 
shows the (visible) records in their (current) order, with one row (or 
just a cell) being highlighted to reflect the "current" record.

The Browse table can be used to browse either database records or a 
two-dimensional array, and allows navigation (and other) code blocks for
customization. It doesn't include any record-, scope-, or order-changing 
features!

>If it works when no Scope or no Filter is set, it must work in same way 
>in ALL other/next variants!

No, it doesn't! The browse table isn't deleting or changing any data or
changing the record pointer or the order -- you programmed that in your
AlaskaBrowse() procedure. The Browse table just shows the changes that 
you made to the record pointer, the sort order (index) and the visible 
records (scope and filter) and the data in those (visible) records. If 
there wouldn't be any browse table used, your code would still change 
the record pointer the same way!

>This my (or your) "workaround" was many-time consuming thing before I 
>find right/truly reason for non-correct record positiong...

It took me about an hour to come up with this code -- I don't usually 
use the XbpBrowse class for databases and haven't run into those issues
before. But if you do something that changes the record pointer, you
need to be aware of the consequences -- no matter if a browse table is
involved or not.

What you perceive as "non-correct record positioning" is in fact totally
correct record pointer positioning! It makes no difference if there is
an XbpBrowse used to show those records or not. You can Delete a record
or Change a Value or the Index Order or Set a Scope or a Filter -- any
one of those operations might invalidate the current record pointer -- 
but the RecNo() won't change until the next DbSkip() or DbGo*(), etc! 

That's how it is designed and specified! A DbGoto() will go to any 
physical record by Record Number, even if the record is "hidden" per 
Index, Scope or Filter. All others -- DbSkip(), DbGoTop(), DbGoBottom(), 
etc. -- will navigate using the (current) logical order and will ignore 
all "hidden" records (outside the Index, Scope and/or Filter). So, doing 
a DbSkip(0) will move the record pointer to the next "logical" record, 
if the current record isn't "visible" anymore.

If you put the record pointer on an "invalid" record, the browse table
will still show that record, as it can't know that you forgot to move 
the record pointer to the one you wanted to show next! If you look at
my changes to your code, you will notice that it fixes several problems
that were in your code:

1) You allowed the program to delete and/or change the "Ghost Record",
   or EoF(), which shouldn't be possible, unless you add a functionality
   to Append a new Record.

2) After you deleted or changed a record -- which might have made that
   record "hidden" -- you didn't adjust the record pointer to the next
   "visible" record, but delegated that to the oBrowse:RefreshAll() 
   method, which won't change the record pointer if there are no valid 
   records to show, so the record pointer would sometimes stay on an
   invalid (out-of-scope) record, instead of going to the "Ghost Record".

3) If the record is still visible after a change, you want that record
   to stay the current record, otherwise, you want the "next" logical
   record to be the current record, unless the "next" logical record 
   would be the "Ghost Record" and there are other, "visible", records
   before the changed record, in which case you want the "previous" 
   logical record to become the current record. This sounds complicated
   because it is!

To accomplish "3)", you must first figure out to which record you might 
want to go after the change and you also need to know after the change 
which record you were on before the change, as you might or might not 
want to go to another record. How in the hell could the Browse table 
"know" any of this? It doesn't even know that you made a change or that 
you invalidated the "current" record! And the next/previous "logical"
records aren't necessary the same before and after your change has been 
made, so it is crucial that this is calculated before any change is made.

Again, how should the Browse table know that you made a change or that
you are planning to make a change? The only way would be to keep track
of the "next logical" and "previous logical" record in some variables 
at all times. And then your "Navigation Code Blocks" would have to use 
and update those values instead of using "DbSkipper()" etc.

If you want an "Editable Database Browse Table" that takes care of all 
those things (and more), you need to either program it yourself or use 
any of the existing third-party programs, like TopDown or Express, etc.
that (probably) have taken care of those issues for you.

-- Andreas

---                                                                      ---
  Andreas Gehrs-Pahl              E-Mail: GPahl@CharterMI.net
  415 Gute Street                     or: Andreas@DDPSoftware.com
  Owosso, MI 48867-4410               or: Andreas@Aerospace-History.net
  Tel: (989) 723-9927           Web Site: http://www.Aerospace-History.net
---                                                                      ---

Andreas,

uch-uch, it looks you informations and "workaround" was correct
(Alaska confirmed me that via private eMail),
it's me who must care about record's pointer.

Your solution works almost great except some new next problems:

a)

1. start attached example
2. go to record e.g. N 124 Faucher Martin and press A for changing name to 
Amsler
   as you can see, record pointer is changed to the top and not to 
new/change record
3. go to record e.g. N 38 Fekete Vladislava and press J for changing name to 
James
   as you can see, record pointer is changed correctly
4. go to record e.g. N 71 Jesenko Primos and press Z for changing name to 
Zdeno
   as you can see, record pointer is changed correctly
5. close window


6. go to last record N 12 Zilkova Natasa and press Z for changing name to 
Zdeno
   as you can see, record pointer is changed correctly, but oBrowse is not 
refreshed completly
   this occurs only when cursow was in first column before changing value or 
also sometimes when
   cursor is set to row mode via XBPBRW_CURSOR_ROW, if cursor was in any 
other column,
   refresing is ok
7. close window

b)

8. there are 8 records in Browse, now just simply go to the bottom pressing 
key Down,
    then back to the by pressing key Up, then againg to the down and so on 
or just press
    PgDn or PgUp and you will see strange things... Browse cannot skip 
down(will stop)
    at some record's positions or records are repetead... Why?!
    this behaviour many times also occurs when filter is set to simply one 
condition,
    but in this example is filter "combined" with 2 conditions for "testing" 
for showing problem ...

Please, can you help me with it?
What I do wrong or where is problem?

TIA
        Zdeno 

Your making this much more complicated then it must be.

The record pointer does not change unless you change it.

Things that change the pointer:
1) dbskip()
2) dbappend()
3) dbgotop()
4) dbgobottom()
5) dbseek()
6) dbsetScope() note pointer will be at the top of the subset defined

If the record pointer changes one of those functions has been called.

Scopes are tricky you will only be able to get to records in the defined
subset. You can not append a record with the scope set since the new
record is blank it does not fall into the subset defined and the record
pointer will not be on the new record. You must clear any scopes before
appending then reset them after. Note that when you reset the scope the
pointer will be at the top of the subset and not on the new record thus
you need to remember the recno() of the new record and move to that
record after reseting the scope. Then you issue a refreshall for the browse.

I'm not even going to try to unscramble your code. My advise start again .

Also you should avoid extra code in event loops. Use the keyboard
callbacks of the XBP's you are using to trigger functions on keypresses.

Jim

Zdenko Bielik wrote:
> Andreas,
> 
> uch-uch, it looks you informations and "workaround" was correct
> (Alaska confirmed me that via private eMail),
> it's me who must care about record's pointer.
> 
> Your solution works almost great except some new next problems:
> 
> a)
> 
> 1. start attached example
> 2. go to record e.g. N 124 Faucher Martin and press A for changing name to 
> Amsler
>    as you can see, record pointer is changed to the top and not to 
> new/change record
> 3. go to record e.g. N 38 Fekete Vladislava and press J for changing name to 
> James
>    as you can see, record pointer is changed correctly
> 4. go to record e.g. N 71 Jesenko Primos and press Z for changing name to 
> Zdeno
>    as you can see, record pointer is changed correctly
> 5. close window
> 
> 
> 6. go to last record N 12 Zilkova Natasa and press Z for changing name to 
> Zdeno
>    as you can see, record pointer is changed correctly, but oBrowse is not 
> refreshed completly
>    this occurs only when cursow was in first column before changing value or 
> also sometimes when
>    cursor is set to row mode via XBPBRW_CURSOR_ROW, if cursor was in any 
> other column,
>    refresing is ok
> 7. close window
> 
> b)
> 
> 8. there are 8 records in Browse, now just simply go to the bottom pressing 
> key Down,
>     then back to the by pressing key Up, then againg to the down and so on 
> or just press
>     PgDn or PgUp and you will see strange things... Browse cannot skip 
> down(will stop)
>     at some record's positions or records are repetead... Why?!
>     this behaviour many times also occurs when filter is set to simply one 
> condition,
>     but in this example is filter "combined" with 2 conditions for "testing" 
> for showing problem ...
> 
> Please, can you help me with it?
> What I do wrong or where is problem?
> 
> TIA
>         Zdeno 
> 
>

Zdeno,

>Your solution works almost great except some new next problems:

The reason for those problems is two-fold. The a) problems are caused by 
the Browse Stabilization when the new oBrowse:RowPos is before (above or
less than) the old oBrowse:RowPos, in which case the first Row might be
selected afterwards (instead of the one you want to jump to).

To (kind of) fix this -- without changing the Browse code or subclassing 
the XbpBrowse -- you need to do a second refresh after the first one, 
after repositioning the record pointer to the desired record. There is 
a small disadvantage to this, though, because the new (changed) record 
will be (still/anyway) moved to the top of the Browse! This can also be
fixed but it isn't pretty. 

The b) problem is IMNSHO simply a wrong implementation of the DbSkipper() 
function, which can't handle your Scoped Filters (or Filtered Scopes?) 
very well. As you have the source code for this function, which is 
located in the "..\XPPW32\Source\Sys\BrowUtil.prg" file, you can easily 
replace and/or fix it, though. I do have the corrected code included.

I very seldom use XbpBrowses -- as I prefer the XbpQuickBrowses -- and I 
never use Scopes or Filters (with the exception of the "Set Deleted On" 
Filter) -- as I prefer Arrays in most cases -- so I don't know if this 
will fix all your issues or not. I have attached a modified version of 
your program, which fixes all the ones you have (so far) mentioned. It 
includes a fixed DbSkipper() function and a modified ShowNewRecord() 
procedure. It also shows "debugging" information in the RootCRT console 
window, which might help you with finding the reasons (and solutions) 
for any other issues yourself.

Also, here are a couple of notes on your coding patterns:

1) You don't need to have a ForceStable() after a RefreshAll(), as the
   RefreshAll() already does the ForceStable(), so it is redundant, and
   won't be executed anyway.

2) Using the (cAlias)-> operator in your event loop makes no sense, unless 
   you also do this in the Browser Navigation CodeBlocks!!! I made that 
   change for you in the attached code.

3) Using Scopes and/or Filters will mess up your Vertical ScrollBars, as
   they will change Size and Position erratically. The reason for this is
   that the return value for DbPosition() is pretty useless when Filters, 
   Scopes and/or (some) Indexes are involved!

Maybe you want to consider using an XbpQuickBrowse() instead?

-- Andreas

---                                                                      ---
  Andreas Gehrs-Pahl              E-Mail: GPahl@CharterMI.net
  415 Gute Street                     or: Andreas@DDPSoftware.com
  Owosso, MI 48867-4410               or: Andreas@Aerospace-History.net
  Tel: (989) 723-9927           Web Site: http://www.Aerospace-History.net
---                                                                      ---

Andreas,

wov, fantastic! Thank you - Thank you - Thank you !!!!!!!!
Now it works, how I need, super!!!!

... and I still think, if this will be default XbpBrowse behavior,
it will save many nervous of many programmers...

May be, Alaska can add your solution to ACSN on their web site.

      Zdeno

Zdeno,

>Hi Andreas,

>please, I kindly ask you, can you help me with "last" thing(I hope)?
>How must looks code when new record will be adding?

Let me respond here, so that everyone (who's interested) can utilize 
this information.

>Because now when I added new record, did put some values into fields
>and then just wanted refresh oBrowse, sometimes it is not
>correcttly refreshed...
>e.g if you press b or B at on second record "Andrea Tompa",
>ok, in this situation no problem, after refreshing new added record 
>"Belkova" is current,
>but now if you go e.g. on record "Christov Peter" and again you 
>press b or B,
>first record " "Blokova rezerva" Ondrejovico" is "current" and 
>not "Belkova"...

>Why? Before "append" I must also now save current record,
>and after adding it then calculate and showing new one?
>If yes, how?

>if nEvent == xbeP_Keyboard
>   do case
>      case mp1 == asc('b') .or. mp1 == asc('B')   Add Record "Belkova"
>         nCurPos := (cAlias)->(RecNo())
>         MsgBox(Str(nCurPos))
>         (cAlias)->(DbAppend())
>         (cAlias)->TYP_FNT := 'N'
>         (cAlias)->AKTIVNA := 'A'
>         (cAlias)->ICO     := '00000117'
>         (cAlias)->NAZOV   := 'Belkova'
>         (cAlias)->OBEC    := 'Nitra'
>         nNewPos := (cAlias)->(RecNo())
>         MsgBox(Str(nNewPos))
>*        (cAlias)->(DbGoTo(nNewPos))
>*        (cAlias)->(DbSkip(0))
>         oBrowse:RefreshAll()
>         MsgBox(Str((cAlias)->(RecNo())))

>      case mp1 == asc('n') .or. mp1 == asc('N')   Add Record "Newton"
>*        if .not. (cAlias)->(Eof())
>            nCurPos := (cAlias)->(RecNo())
>            MsgBox(Str(nCurPos))
>*           nNewPos := GetNewRecordPointer(cAlias, oBrowse, nCurPos, 'Adding Record: ')
>            (cAlias)->(DbAppend())
>            (cAlias)->TYP_FNT := 'N'
>            (cAlias)->AKTIVNA := 'A'
>            (cAlias)->ICO     := '00000111'
>            (cAlias)->NAZOV   := 'Newton'
>            (cAlias)->OBEC    := 'Nitra'
>            nNewPos := (cAlias)->(RecNo())
>            MsgBox(Str(nNewPos))
>            (cAlias)->(DbGoTo(nNewPos))
>            MyDbSkipper(nNewPos/*nToSkip*/)
>*           (cAlias)->(DbSkip(0))
>*           oBrowse:RefreshAll()
>            MsgBox(Str((cAlias)->(RecNo())))
>            ShowNewRecord(cAlias, oBrowse, nCurPos, nNewPos)
>*        endif

>      case mp1 == asc('d') .or. mp1 == asc('D')   Delete Record

>Thanks in advance & Regards

>              Zdeno

It is actually much simpler than this. Just select the new record with
"ShowNewRecord()" after the append. Please note the reversal of the
nCurPos vs nNewPos, as you want to stay on the current record, only if 
the newly added record falls outside of the Scope/Filter.

   case mp1 == asc('b') .or. mp1 == asc('B')    Add Record "Belkova"
      nCurPos := (cAlias)->(RecNo())
      (cAlias)->(DbAppend())
      (cAlias)->TRAN_CISLO := nNewPos := (cAlias)->(RecNo())
      (cAlias)->TYP_FNT    := 'N'
      (cAlias)->AKTIVNA    := 'A'
      (cAlias)->ICO        := '00000117'
      (cAlias)->NAZOV      := 'Belkova'
      (cAlias)->OBEC       := 'Nitra'
      QOut('Added new record "Belkova": ' + alltrim(str(nNewPos)) + ;
      ' (ID: "' + alltrim(str((cAlias)->TRAN_CISLO)) + '")')
      ShowNewRecord(cAlias, oBrowse, nNewPos, nCurPos)

   case mp1 == asc('n') .or. mp1 == asc('N')    Add Record "Newton"
      nCurPos := (cAlias)->(RecNo())
      (cAlias)->(DbAppend())
      (cAlias)->TRAN_CISLO := nNewPos := (cAlias)->(RecNo())
      (cAlias)->TYP_FNT    := 'N'
      (cAlias)->AKTIVNA    := 'A'
      (cAlias)->ICO        := '00000111'
      (cAlias)->NAZOV      := 'Newton'
      (cAlias)->OBEC       := 'Nitra'
      QOut('Added new record "Newton": ' + alltrim(str(nNewPos)) + ;
      ' (ID: "' + alltrim(str((cAlias)->TRAN_CISLO)) + '")')
      ShowNewRecord(cAlias, oBrowse, nNewPos, nCurPos)

Using "MsgBox()" isn't a good idea in this case, because you will create 
additional events (like focus changes) that might change the default 
behavior of the routine. Use "QOut()" instead, as it doesn't affect the 
Browse Dialog, and won't influence the Browse behavior.

-- Andreas

---                                                                      ---
  Andreas Gehrs-Pahl              E-Mail: GPahl@CharterMI.net
  415 Gute Street                     or: Andreas@DDPSoftware.com
  Owosso, MI 48867-4410               or: Andreas@Aerospace-History.net
  Tel: (989) 723-9927           Web Site: http://www.Aerospace-History.net
---                                                                      ---

Hi Andreas,

again, perfect work and comments!
Thanks!

         Zdeno

Andreas,

> Maybe you want to consider using an XbpQuickBrowse() instead?
hmmm, what will be advantage/benefit or minus/handicap with that solution?

Will be it "easy" way to change program's logic and navigation's logic
from XbpBrowse() to XbpQuickBrowse(), e.g. for "our" test program?

From first read of doc it looks it is not so good configurable
at column level (all columns are in "one line/object"),
but it looks it has "super-speed".

         Zdeno

Hello Zdenko:
good morning.
The greatest trouble that I know is that you can not set code blocks for the 
column in a native way. For accomplishing it you must use functions that 
recently changed its name.

Beling
Best regards

Zdenko Bielik escreveu:
> Andreas,
> 
>> Maybe you want to consider using an XbpQuickBrowse() instead?
> hmmm, what will be advantage/benefit or minus/handicap with that solution?
> 
> Will be it "easy" way to change program's logic and navigation's logic
> from XbpBrowse() to XbpQuickBrowse(), e.g. for "our" test program?
> 
> From first read of doc it looks it is not so good configurable
> at column level (all columns are in "one line/object"),
> but it looks it has "super-speed".
> 
>          Zdeno 
> 
>