vpwhist contents

[dunkers]

Reading a recent thread about SE performance (which may be relevant to me, but might not) I decided to check my vpwhist file. It is small at 160K and 1653 lines, but there are many repeated parts. For instance, There are 22 instances of:

Code: [Select]

AAAAAwAAAAEAAAAD2gAAAAIAMAAAAAAAAAAwAAAE...<3725 char line>
QTOOLBAR 1 0
AAAA/wAAAAD9AAAAAAAABLAAAAO2AAA...<105 char line>
And 22 instances of "_tbprojects_form T=0", but these don't always precede the above three lines. In fact, the preceding and following lines seem to be without rhyme or reason.

Presumably the long lines are blobs, but what do they represent?

[Graeme]

It's normal, you don't need to be concerned about it.  Have a look in vrestore.slk it has similar stuff.  The gobbledigook seems to be some kind of ascii binary, why there are so many AAA characters I have no idea.

If you want to have a look at the code that generates it, have a look at the autorestore_layout function in mainwindow.e.  This function does both save and restore.  For saving window layout the option argument to the function is empty string, for restore it is "r".  The last part of the function is further below.
1. it calls save_pos so that it can come back to this line at the end
2. it writes a list of known toolbars with "F=..." at the end
3. it writes a list of active toolbars with "T=..." at the end
4. it calls _MDISaveState (in the slick core) and writes it to a single line  - this is the long line of gobbledigook
5. it calls autorestore_qtoolbars  - this calls _QToolbarGetState and writes another shorter line of gobbledigook, followed by a  "QTOOLBAR"  line  - and save-pos restore-pos are used to put this line first (re-orders)
6. It then calls restore_pos and writes a line such as APP_LAYOUT: 68 1 46 17 4 M 0  - so this ends up at the start and says how many lines of data there are in this block.


I think I once knew why there were twenty something instances of the above stuff but I've forgotten the exact reason other than the obvious which is that fullscreen layout gets remembered separately from standard layout.  It's in the workspace history file because workspaces remember their own screen layout if you want them to.

Code: [Select]

   } else {

      save_pos(auto p);

      nRestoreLines := 0;
      _str formName;
      ToolWindowInfo twinfo;

      // Tool-window info
      nRestoreToolWindowInfo := g_toolwindowtab._length();
      foreach ( formName => twinfo in g_toolwindowtab ) {
         insert_line(formName" F="twinfo.flags);
      }

      // Visible tool-windows
      int wids[];
      tw_get_registered_windows(wids);
      nRestoreToolWindows := 0;
      int i, n = wids._length();
      for ( i = 0; i < n; ++i ) {
         ++nRestoreToolWindows;
         insert_line(wids[i].p_name" T="wids[i].p_tile_id);
      }

      _str state;
      _MDISaveState(state, WLAYOUT_MAINAREA);
      insert_line(state);
      // +1 for encoded state
      nRestoreLines += nRestoreToolWindowInfo + nRestoreToolWindows + 1;

      // Toolbars
      nRestoreToolbarLines := 0;
      autorestore_qtoolbars(option, nRestoreToolbarLines);
      nRestoreLines += nRestoreToolbarLines;

      orig_line := p_line;
      restore_pos(p);
      insert_line(restoreName": "(nRestoreLines)" "LAYOUT_VERSION" "(nRestoreToolWindowInfo)" "(nRestoreToolWindows)" "(nRestoreToolbarLines)" "_mdi.p_window_state" "_tbFullScreenQMode());
      p_line = orig_line + 1;
   }
}


[dunkers]

Thanks for the info, Graeme