Here are some things in Kalani that you should know about:

Components and Controls

• There are three kinds of component you can create here,  and you need to know which system class to inherit from,  depending on your control's intended capabilities: 
  • Use the  UserControl  class to contain existing controls,  which you are combining to form a new control.   This will draw your control for you.  
  • The  Control  class will not draw for you.  
    • Kalani's example starts on page 312.
    • You must alter the first line of code  (the one naming the class)  so as to inherit from class  Control,  not  UserControl
    • You must invoke the  Invalidate  method whenever the control is to be redrawn
    • You must write a  Paint  method for the control for it to draw itself
  • Use the  Component  class when your control has no visual aspect,  like a Timer.
    • Kalani's example starts on page 315.
    • This example includes the use of an icon which shows in the Tool Box.   Kalani's description  (on pages 318-319)  of the attribute necessary to cause this  (the  ToolboxBitmap  attribute) may be inadequate.   You might go to .NET help and look up "ToolboxBitmapAttribute class, about ToolboxBitmapAttribute class"
• To create a control,  use the C# Windows Control Library template.  
  • (According to the box on page 289 of Kalani,  this template will not be found in the standard edition of Visual Studio.   It is present in the academic version of Visual Studio.)
  • To test a control, you must create a DLL containing the code for that control,  and then create another Windows app to host that control,  adding the control's DLL as a reference.  
• Adding events and event handlers to a control.   See the example in Kalani, pages 295-298.
  • Remember that you need to write this stuff only if you are actually writing code that creates and publishes events.   For simple Windows programming,  you only need to tell the IDE which event you want to program  (as we have already done several times in class),  and this wiring is all done for you.  
  • Event handler.   You write this,  and you put it in your local program.   It has two arguments:
    • the publisher (or "sender") of the event
    • an object inheriting from  EventArgs.   This object's name,  by convention,  ends with  EventArgs
  • Delegate
    • It's a sort of function pointer
    • Grammar:

                 public delegate void ChangedEventHandler (object sender, XEventArgs args);

  • Event
    • It uses the delegate in its definition
    • Grammar (here,  ChangedEventHandler  is the delegate,  and  Changed  is the event):

                 public event ChangedEventHandler Changed;

  • Notification
    • The class publishing the event notifies the subscribers
    • If the event  (here,  Changed)  is null,  it means that it has no subscribers.   The program must check for null before causing notification.   (I don't know why the event can't do this for itself.   After all,  it knows how to notify all its subscribers without any assistance from the caller.)   Warning:  I have seen a question about this code more than once,  sometimes incorrectly missing the check for null.  
    • Grammar:

                   protected virtual void OnChanged (XEventArgs e) 
                 {
                   if (Changed != null)
                   {
                     Changed(this, e);
                   }
                 }

    • The subscriber must use code of the following form.   Again,  you might be asked about the form of the code in this command,  sometimes given incorrectly with "=" instead of "+=".   (In this code,  the event is named  Changed,  and the local handler for this event is  X_Changed):

                  Changed += new ChangedEventHandler (X_Changed);

• Visual inheritance
  • You can use the "Inheritance Picker" to specify the base for an inherited control
• Hosting a control in Internet Explorer
  • You need a web server,  such as IIS  (Internet Information Server)  for this
  • You create a virtual directory
  • You specify the location of the DLL holding the control with an entry in the HTML or ASP.NET page in that directory,  of the form

            classid = "http://localhost/DirectoryName/AssemblyName.dll#ControlName"

    The "#" is important because it's just about the only part of this hosting business I've ever seen in a test question.

Assemblies

• You must know some basic facts about what an "assembly" is—
  • It is a logical collection of files, not a single physical file
  • It typically includes .dll  or .exe  files, along with various kinds of resource files, such as
    • graphics files
    • data files containing translations of strings used in the program, for use in globalization
  • Exactly one file in the assembly contains the assembly manifest
• The assembly manifest contains metadata for the assembly
  • It contains
    • Name and version of the assembly.   (All resources in the assembly share the same version number.)
    • A list of all the files in the assembly—their names and hash values
    • The compile-time dependencies of the assembly
    • Culture or language
    • Permissions required by this assembly
  • You can look at the assembly manifest by using the  ildasm  tool  (the intermediate language disassembler)
• Single-file assemblies vs.  multi-file assemblies
  • Single-file assemblies
    • these are what you have been using so far in the course
    • Using  ildasm  will show the references to other assemblies
  • Multi-file assemblies
    • These cannot be created with the .NET IDE
    • You use command line operations to create them
      • You must first compile each module, using  csc  with the  /t:module  option
      • You then create the assembly using  csc  with the  /t:library  option,  using  /addmodule  to list the modules to go into the assembly
      • This gives a .dll  that contains just the manifest and no code
• Static vs.  dynamic assemblies
  • Static assemblies are produced by the compiler and linker.   They are what you've been doing all along
  • Dynamic assemblies are created at run time.   They require a knowledge of the  reflection  facility,  which is not required for the certification exam
• Private vs. shared assemblies
• Private assemblies:
  • They are what you've been creating all along
  • They are copied into the directory where they are needed
  • They are not shared by many apps,  if in fact they are shared by more than one
• "Public" assemblies are called shared assemblies.  
  You place them in the GAC—the Global Assembly Cache
  • The GAC requires that every assembly placed in it has a strong name,  which comprises
    • an assembly name
    • a version number
    • a culture (i.e., a language and country)
    • a public key
    • optionally, a digital signature
  • The GAC is very important for the certification test,  and will be covered in detail in chapter 13:  Deployment
  • You can inspect the contents of the GAC by using Internet Explorer
    • .NET adds the  Shfusion.dll  for such viewing
    • The directory you should look at is something like

                      C:\Windows\Assemblies

    • The GAC is not as simple as this view makes it appear to be
    • Assemblies marked "Native Image" have been precompiled in native code before they were put into the GAC,  by use of the Native Image Generator,  ngen.exe.   This avoids the use of the JIT at loading,  making the first invocation faster.
• Resource assemblies
  • Content  build  (the default):  resources are held in separate files,  which must be distributed with the app
  • Embedded Resources  build:  resources are held in the assembly itself
  • The steps in creating embedded resources:
    • .NET creates an XML file with the extension .resx,  which holds the resources as key-value pairs
    • At compilation, .resx  file resources are embedded into a binary file with the extension .resources
    • This binary .resources  file is embedded into the code assembly
  • There are some .NET classes that handle resource files directly:
    • ResourceManager  can get resources at run time—specifically,  it can read resource-only assemblies  (example,  page 338)
    • ResourceReader  reads  from binary .resources  files
    • ResourceWriter  writes  to binary .resources  files
    • ResXResourceReader  reads  from XML .resx  files
    • ResXResourceWriter  writes  to XML .resx  files
  • Culture-specific assemblies are a specific kind of resource-only assembly
    • They contain culture-specific information,  such as translations of various text strings that occur in the app
    • They are also called  satellite assemblies
    • To get .NET to create them,
      • set the  Localizable  property of the Form  true
      • Set a language different from English-US
      • This will create a set of  .resx  files
      • Different sets of  .resx  files are created for each language.   Since these are in XML,  they can  be edited by any text editor.
      • Folders for these resources are created in the  bin\debug  directory,  typically with names such as Project.resources.dll 
    • Culture-specific assemblies will come up in detail later,  in the  chapter on  "Globalization".

    Test 1:  questions  20  (page 365;  answer:  page 393),  22,  31,  32.

    Test 2:  questions  13  (page 409;  answer:  page 441),  55,  56,  57.

(Some of these questions may duplicate those in long Kalani.   Both texts are listed here.)