What does the AllowResetPrevPos (ALLOWRESETRPREVPOS) EditTable property control? How is this used?

This property is set to True on edittables that have been migrated from OI9, although the default setting for new edittables is False. For some reason (in the event code), single column edittables in our windows spin in a loop when they get focus. It appears to be related to DEFPROP becoming null when created, and thus no cell is available.

Setting the AllowResetPrevPos to False stops this behaviour. The edittable retains all visible rows when created, which is the same behaviour in OI9.

Also, the ID of this property is ALLOWRESETRPREVPOS - is that R supposed to be there??

Cheers, M@

Vernon Systems

By observation it seems that this property controls the PSSX_EDT_LISTBOXRENDERSTYLE$ bit (0x400) of PSPOS_PSTYLE<0,0, 2>, according to PS_EDITTABLE_EQUATES. This appears to be a SELECTIONSTYLE that would render selected rows in the classic solid color. Although it doesn't seem to make a difference in this regard, and SELECTIONSTYLE is a ListBox property anyway.

Anyhoo - after going full circle, it appears I can resolve my issue with migrated forms just by forcing a recompile of the window!

Cheers, M@

Vernon Systems

Hi M@,

ALLOWRESETPREVPOS property:

In v9, when you set the LIST or ARRAY properties the PREVSELPOS property was not updated - so if it was set to something like (2, 20) and you then loaded a new LIST with 10 rows it still held the same value.

By default in v10 PREVSELPOS is reset back to 1,1 when you load a new ARRAY or LIST.

Eventually (of course) we found this broke some migrated client systems so we had to give the option to allow for the different behavior. Hence migrated v9 systems by default don't reset PREVSELPOS, but new EditTables in v10 do unless you don't want them to.

The style bits in question are a little out of date - this is what they should say:

   // Extended PS Style equates - (Properties held in window style bits in 

   //                              PSPOS_PSSTYLE$ <0,0,2> )

   

   equ PSSX_EDT_HSCROLLBAR$                        to 0x00000001

   equ PSSX_EDT_VSCROLLBAR$                        to 0x00000002

   equ PSSX_EDT_DEFROWHEIGHTSET$                   to 0x00000004

   equ PSSX_EDT_COLHDRHEIGHTSET$                   to 0x00000008

   equ PSSX_EDT_ROWSTRIPE$                         to 0x00000010

   equ PSSX_EDT_ALLOWROWCLIPCOPY$                  to 0x00000020

   equ PSSX_EDT_ALLOWROWCLIPPASTE$                 to 0x00000040

   equ PSSX_EDT_ACCEPTRETURN$                      to 0x00000200

   equ PSSX_EDG_ALLOWRESETPREVPOS$                 to 0x00000400

   equ PSSX_EDG_SHOWSELNOFOCUS$                    to 0x00000800

   equ PSSX_EDT_SUPPRESSCELLTOOLTIPS$              to 0x00001000

The property name, as you quite rightly noticed, was spelled incorrectly and has now been fixed for the next release.

Cheers

Carl Pates

Ahh! - thanks Carl

This property is set to True on edittables that have been migrated from OI9, although the default setting for new edittables is False.

.. migrated v9 systems by default don't reset PREVSELPOS, but new EditTables in v10 do unless you don't want them to.

So if I understand correctly from this - in Form Designer setting AllowResetPrevPos to True will not reset PREVSELPOS on setting DEFPROP; whereas setting AllowResetPrevPos to False will reset PREVSELPOS. If so it seems the boolean values are the wrong way around?

(and I assume _EDG_ should be _EDT_, right? ;) )

Cheers, M@

Vernon Systems

Hi M@,

*sigh* - Maybe I shouldn't be allowed to answer anything first thing in the morning …

AllowResetPrevPos is True: PREVSELPOS is reset to (1,1) when ARRAY or LIST is set (this can be via DEFPROP)

AllowResetPrevPos is False: PREVSELPOS is not reset when ARRAY or LIST is set (this can be via DEFPROP)

i.e. from the EditTable C++ code:

      if ( this->IsAllowResetPrevPos() ) {

         m_cpPrevious.SetPos( 0, 0 ); // (Reset to 1,1)

      }

      else {

         // Reset the PrevSelPos to it's original value if we can

         m_cpPrevious = cpSavePrevious;

      }

So having said that the migration tool should _not_ be setting this property to True for v9 forms - the fact that this style bit is being set there is a bug.

If you're bored and need something to read then here's why it is:

Once upon a time before v10 was released we had a property called SELECTIONSTYLE that was originally controlled by two bits:

   equ PSSX_EDT_LISTBOXRENDERSTYLE$             to 0x00000400; // SELECTIONSTYLE property

   equ PSSX_EDT_TREEVIEWRENDERSTYLE$            to 0x00000800; // SELECTIONSTYLE property

What SELECTIONSTYLE did for the EditTable was changed the way selected rows were painted when the edit table has focus - if it was "listbox style" then selected rows were painted regardless of focus (as they are in v9), if it was "treeview" style then were painted according to the "selected cell without focus" style , if neither bit was set then it was controlled by the PS visual style manager - for XP systems it would be "listbox" - for Vista+ it would be "treeview" (XP had no concept of the sel-no-focus type styling). This meant that the migration tool had to set PSSX_EDT_LISTBOXRENDERSTYLE$ to force v9 compatibility.

Fast-forward a little later and it was decided to deprecate SELECTIONSTYLE and have a simple SHOWSELNOFOCUS property that either allowed "sel-no-focus" styling or not (the PS visual style manager stopped being so picky about XP styling especially when XP support was withdrawn by MS part-way through the v10 development).

So the above style bits became this instead:

   equ PSSX_EDT_ALLOWRESETPREVPOS$                 to 0x00000400

   equ PSSX_EDT_SHOWSELNOFOCUS$                    to 0x00000800

Because I missed changing this in the migration tool it was still setting PSSX_EDT_LISTBOXRENDERSTYLE$, which of course is now PSSX_EDT_ALLOWRESETPREVPOS$.

So bottom line - for v9 backwards compatibility AllowResetPrevPos should NOT be set during the migration. Also it is not being set by default in the FormDes.

So, hopefully that's that, and we can draw line under the saga of ALLOWRESETPREVPOS.

Cheers

Carl Pates

Hi M@,

*sigh* - Maybe I shouldn't be allowed to answer anything first thing in the morning …

AllowResetPrevPos is True: PREVSELPOS is reset to (1,1) when ARRAY or LIST is set (this can be via DEFPROP)

AllowResetPrevPos is False: PREVSELPOS is not reset when ARRAY or LIST is set (this can be via DEFPROP)

i.e. from the EditTable C++ code:

      if ( this->IsAllowResetPrevPos() ) {

         m_cpPrevious.SetPos( 0, 0 ); // (Reset to 1,1)

      }

      else {

         // Reset the PrevSelPos to it's original value if we can

         m_cpPrevious = cpSavePrevious;

      }

So having said that the migration tool should _not_ be setting this property to True for v9 forms - the fact that this style bit is being set there is a bug.

If you're bored and need something to read then here's why it is:

Once upon a time before v10 was released we had a property called SELECTIONSTYLE that was originally controlled by two bits:

   equ PSSX_EDT_LISTBOXRENDERSTYLE$             to 0x00000400; // SELECTIONSTYLE property

   equ PSSX_EDT_TREEVIEWRENDERSTYLE$            to 0x00000800; // SELECTIONSTYLE property

What SELECTIONSTYLE did for the EditTable was changed the way selected rows were painted when the edit table has focus - if it was "listbox style" then selected rows were painted regardless of focus (as they are in v9), if it was "treeview" style then were painted according to the "selected cell without focus" style , if neither bit was set then it was controlled by the PS visual style manager - for XP systems it would be "listbox" - for Vista+ it would be "treeview" (XP had no concept of the sel-no-focus type styling). This meant that the migration tool had to set PSSX_EDT_LISTBOXRENDERSTYLE$ to force v9 compatibility.

Fast-forward a little later and it was decided to deprecate SELECTIONSTYLE and have a simple SHOWSELNOFOCUS property that either allowed "sel-no-focus" styling or not (the PS visual style manager stopped being so picky about XP styling especially when XP support was withdrawn by MS part-way through the v10 development).

So the above style bits became this instead:

   equ PSSX_EDT_ALLOWRESETPREVPOS$                 to 0x00000400

   equ PSSX_EDT_SHOWSELNOFOCUS$                    to 0x00000800

Because I missed changing this in the migration tool it was still setting PSSX_EDT_LISTBOXRENDERSTYLE$, which of course is now PSSX_EDT_ALLOWRESETPREVPOS$.

So bottom line - for v9 backwards compatibility AllowResetPrevPos should NOT be set during the migration. Also it is not being set by default in the FormDes.

So, hopefully that's that, and we can draw line under the saga of ALLOWRESETPREVPOS.

Cheers

Carl Pates

Confirmed it IS being set on migration comple.

Confirmed it IS being set on migration comple.

*compile

Hi Carl,

Nice! Love a good story, and that explains everything :)

Good to know about SHOWSELNOFOCUS too! We have legacy promoted LOSTFOCUS event code that would manually unselect rows when leaving the edittable.

Cheers, M@

Vernon Systems

View this thread on the Works forum...