scp.txt

动态提示控件

System Control Pack v0.98.5 Beta

This is BETA software.  It is not guaranteed to do ANYTHING useful at all.

                      R E A D   T H I S   N O W ! ! !

I hope that got your attention.  This component requires a unit that
provides access to the Win95/NT 4.0 Shell Namespace API.  Delphi 2.0 did not
include this import, but the v2.01 update does.  Also, Mr. Pat Ritchey was
kind enough to write one, which I think was the basis for Borland's (same
bugs in both units, must be the same).  C++Builder 1.0's ShlObj.pas also suffers
from the same problems.  Regardless of which you use, you will have to do some
extra work because both contain errors that will prevent this component from
working properly (or even compiling, probably).  To implement these changes,
read the ShellFix.txt file that should have been included with this file.
If you use Delphi 3 or higher, or C++Builder 3 or higher, you will not need to
worry about any of this.  No bugs (that effect these components anyway).


Description:
  Tree view, list view, and combobox controls that act like the controls in the
  Windows Explorer.


Contact Information:
  The lateset version will always be available on the web at:
    http://www.delphifreestuff.com
  If you have any questions, comments or suggestions, please use the Delphi
  Free Stuff Support Forum at: 
    http://www.delphifreestuff.com/discus/
  If, for some reason, you can not use the web-based support forum, you can
  email me at [e-mail].  However, the support forum will
  always take precedence over direct email since it provides a resource that
  others can use when they have a problem.  Every message posted to the forum
  is emailed directly to this account, so emailing me directly will not get 
  your message to me any faster.  It will only make the message less important
  for me to respond to since only one person (you) is benefiting from it
  instead of everyone interested.  Having said all that, please do email me 
  directly if it is regarding something that isn't really support related, 
  i.e. just to say thanks (as novel as that idea is).  


Installation:
  Delphi 1:
    * This component is not compatible with Delphi 1.
  
  Delphi 2, C++Builder 1:
    * Select the 'Component | Install' menu item.
    * In the Install Components dialog, click the Add button.
    * In the Add Module dialog, enter the full path name of the component's
      registration unit (the unit that ends with 'Reg.pas', i.e.
      'BrowseDrReg.pas') and click OK.
    * In the Add Module dialog, click OK.
    * The component library will be rebuilt and a new tab named 'DFS' will be
      available on the Component Palette.

  Delphi 3, 4, 5, C++Builder 3 & 4:
    * Do one of the following:
      + Create a new package by selecting File | New and choosing Package from
        the New tab in the dialog.
      + Open an existing package file.  I suggest you do this if you already 
        have a package that you like to use for small, third party components.
        I specifically have a package named "3rdParty.dpk" that I use for 
        small components that come from other people.  Or, if you are using
        several of my components, you might create a "DFS.dpk" package and 
        use it for all of my DFS components.
    * In the resulting package window, click the Add button.
    * In the Add dialog, on the Add Unit tab, enter the full path name of the
      component's registration unit (the unit that ends with 'Reg.pas', i.e.
      'BrowseDrReg.pas') and click OK.
    * You may want to add the other source files (*.pas) to the package as
      well in the same manner as you did the registration unit.  While this is
      not required, not doing it will cause compiler warnings when the package
      is compiled.  The component will function fine either way, but I
      personally find the warnings very irritating and am not happy until
      every compiler warning and hint is gone.  NOTE:  If you use C++Builder 3,
      do not install the other source units.  See Known Issuses section below.
    * If this package is new, or it has never been installed, click the
      Install button in the package window.  If this package is already
      installed in Delphi, click the Compile button.

  C++Builder 5 and up:
    * Perform the "Delphi 3 and up, C++Builder 3 and up" steps above, except
      for the last step (Compile or Install).
    * Select the package the component has been added to, and choose 
      Project | Edit Option Source to open the package options in the editor.
    * In the entry for PFLAGS, add the "-LUvcl50" option.  For example:
        <PFLAGS value="-$YD -$W -$O -v -JPHNE -M -LUvcl50"/>
    * Perform the final step from above, Compile or Install.
    * For Borland's official word on this situation, open the C++Builder help
      file and search the index for "dsgnintf.dcu" and see the "Compiling
      packages with DsgnIntf" section.

  Delphi 6 and up:
    * Perform the "Delphi 3, 4, 5, C++Builder 3 & 4" steps above, except
      for the last step (Compile or Install).
    * Add the DesignIDE package to the Requires list of the package into which
      the component is being installed.
    * Perform the final step from above, Compile or Install.
    * This is necessary because of changes to the design-time support units
      introduced in Delphi 6.  For complete information, see the Del6New.hlp
      file in your Delphi 6 Help directory.  In the index, search for
      "upgrade issues" and in the resulting list of topics, select the
      "DsgnIntf renamed and related changes" topic.


Conditional Defines:
  These units makes extensive use of conditional defines to control many aspects
  of how and what things are compiled.  Usually these are used to effect code
  size or change how a feature works, but some are also for debugging purposes.
  The following is a list of the defines that are used and how.  These defines
  are all found in the SystemControlPack.inc file.  The prefix used in each
  name identifies what is effected:
    DFS   --  Prefix I use for all my defines to avoid clashing with other
              defines that may be in use.  DFS = Delphi Free Stuff
    SCP   --  Indicates that the define effects all components.  SCP = System
              Control Pack
    STV   --  Indicates that the define effects only the TSystemTreeView
              component.  STV = System Tree View
    SLV   --  Indicates that the define effects only the TSystemListView
              component.
    SCB   --  Indicates that the define effects only the TSystemComboBox
              component.  Currently, there are none of these.
  The defines used are as follows:

  * DFS_SCP_SYSTREEVIEW, DFS_SCP_SYSLISTVIEW, DFS_SCP_SYSCOMBOBOX: If you
      undefine any of these, then that/those components will no longer be
      compiled.  For example, if you undefined DFS_SCP_SYSLISTVIEW, the
      TSystemListView component will not be compiled, and the tree view and
      combo box components will no longer have a ListView property to link to.
      This resulted in a 70k saving in the compiled EXE of a test app that used
      only the TSystemTreeView component.  The down side to this is that if you
      use TSystemListView for some projects and not for others, you will either
      have to leave it enabled for all, or have one heck of a code maintenance
      nightmare.  One solution to this could be to remove the
      DFS_SCP_SYSLISTVIEW define from the include file completely and add it to
      the Project | Options | Directories/Conditionals of the design-time
      package you install the component in.  Then, you would add
      DFS_SCP_SYSLISTVIEW to the options of the projects that need it, and leave
      it out of those that don't. This would allow you to control what is
      compiled into the Delphi IDE independant of what is compiled into your
      projects without having to change the SystemControlPack.inc file in
      between.  I have not tested this solution, but it works in theory.  :)
  * DFS_STV_FASTMODE and DFS_SLV_FASTMODE: These defines are not enabled by
      default.  If you enable them, the components will populate/display much
      faster.  The reason is that the actual item data such as the Caption and
      subitem text, the image index, etc. aren't retrieved when the list/tree is
      populated.  Instead, the system will ask (via a CN_NOTIFY message) for the
      data when it needs a particular item's data and it is supplied only then.
      So, it doesn't take nearly as long to add a large number of items.  But
      (there's always a price to be paid), you will lose access to this data via
      the Nodes (treeview) or Items property (listview).  That means you won't
      be able to do stuff like:

        ShowMessage(MySysListView.Items[0].Caption);

      However, you will still be able to do the equivalent using stuff like:

        ShowMessage(MyList.GetFullPath(MyList.Selected));

      So, if you need the text or image index stuff, leave the define off. But,
      if you don't, turn it on by removing the period and it'll be faster. In my
      informal testing, listing my windows directory went from 12 seconds to 2
      seconds.  You'll only see these big gains on directories with a lot of
      files, though.  Many thanks go to Andei V. Rasskazov for pointing this
      technique out.
  * DFS_SLV_USE_ENHLISTVIEW and DFS_SLV_USE_EXTLISTVIEW: These are not enabled
      by default.  They are useful only if you also have my TEnhListView and
      TExtListView components.  You will need v3.13 or later of these components
      for this to work.  Enabling ONE of these (never enable both) will cause
      TSystemListView to descend from the corresponding TEnh/ExtListView class,
      giving you all of that class' features as well.  WARNING:  This is just a
      simple implemenation currently, and there are likely to be problems.  Only
      use these if you want to help me work out the bugs in it.  Defining either
      of these will also cause DFS_SLV_USING_ELV to be defined.  I use this
      internally when I want to know if either of the above are defined and
      I don't care which one.  You should not define DFS_SLV_USING_ELV yourself.
  * DFS_STV_FILECHANGES: Controls whether the treeview will "watch" the
      directory that is currently displayed for changes, i.e. a new directory
      or file created, an existing one deleted, etc. and automatically refresh
      when this happens.  This was originally put in so that this feature could
      be turned off during development if nasty bugs were found.  However, that
      was quite a while back, and "change watching" seems to be quite stable
      now.  The only reason you might want to turn it off now is to save
      yourself the 3.5 kb of space it adds to your compiled EXE.  This define
      will probably be removed entirely unless someone makes a strong case for
      leaving it.
  * DFS_DEBUG: This is a define that I use internally for debugging the
      components.  It causes a unit to be used that is not distributed, so it
      is most likely useless to anyone but me.