Syntax:
add-method generic-function method => generic-function
Method Signatures:
add-method (generic-function standard-generic-function) (method method)
Arguments and Values:
generic-function---a generic function object.
Description:
The generic function add-method adds a method to a generic function.
If method agrees with an existing method of generic-function on parameter specializers and qualifiers, the existing method is replaced.
Examples: None.
Affected By: None.
Exceptional Situations:
The lambda list of the method function of method must be congruent with the lambda list of generic-function, or an error of type error is signaled.
If method is a method object of another generic function, an error of type error is signaled.
See Also:
defmethod, defgeneric, find-method, remove-method, Section 7.6.3 (Agreement on Parameter Specializers and Qualifiers)
Notes: None.


We optimize mices!
- leverage holistic mindshare
- monetize open-source bandwidth
- seize transparent portals
- unleash proactive methodologies
- unleash efficient e-services
- evolve plug-and-play markets
- deliver clicks-and-mortar synergies
- extend B2B web-readiness
- embrace out-of-the-box users
- strategize impactful functionalities
- seize intuitive portals
- streamline transparent action-items
- synergize end-to-end platforms
- whiteboard B2C schemas


{% extends 'bibtex/base.html' %} {% load staticfiles %} {% block content %} {% if username %} {% if not entry %}
You are adding as the user {{username}}. In order to edit this entry in the future you will have to use the same user account. If this is incorrect, please log out and log in as a different user.
{% else %}Please note: Because of the server we have been assigned, file uploads can be very slow. Please be patient.
You are not logged in to the departmental webpages.
{% endif %} {% endblock %}


CPack WIX Generator¶
CPack WIX generator specific options
Variables specific to CPack WIX generator¶
The following variables are specific to the installers built on Windows using WiX.
-
CPACK_WIX_UPGRADE_GUID
¶ Upgrade GUID (
Product/@UpgradeCode
)Will be automatically generated unless explicitly provided.
It should be explicitly set to a constant generated globally unique identifier (GUID) to allow your installers to replace existing installations that use the same GUID.
You may for example explicitly set this variable in your CMakeLists.txt to the value that has been generated per default. You should not use GUIDs that you did not generate yourself or which may belong to other projects.
A GUID shall have the following fixed length syntax:
XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
(each X represents an uppercase hexadecimal digit)
-
CPACK_WIX_PRODUCT_GUID
¶ Product GUID (
Product/@Id
)Will be automatically generated unless explicitly provided.
If explicitly provided this will set the Product Id of your installer.
The installer will abort if it detects a pre-existing installation that uses the same GUID.
The GUID shall use the syntax described for CPACK_WIX_UPGRADE_GUID.
-
CPACK_WIX_LICENSE_RTF
¶ RTF License File
If CPACK_RESOURCE_FILE_LICENSE has an .rtf extension it is used as-is.
If CPACK_RESOURCE_FILE_LICENSE has an .txt extension it is implicitly converted to RTF by the WIX Generator. The expected encoding of the .txt file is UTF-8.
With CPACK_WIX_LICENSE_RTF you can override the license file used by the WIX Generator in case CPACK_RESOURCE_FILE_LICENSE is in an unsupported format or the .txt -> .rtf conversion does not work as expected.
-
CPACK_WIX_PRODUCT_ICON
¶ The Icon shown next to the program name in Add/Remove programs.
If set, this icon is used in place of the default icon.
-
CPACK_WIX_UI_REF
¶ This variable allows you to override the Id of the
<UIRef>
element in the WiX template.The default is
WixUI_InstallDir
in case no CPack components have been defined andWixUI_FeatureTree
otherwise.
-
CPACK_WIX_UI_BANNER
¶ The bitmap will appear at the top of all installer pages other than the welcome and completion dialogs.
If set, this image will replace the default banner image.
This image must be 493 by 58 pixels.
-
CPACK_WIX_UI_DIALOG
¶ Background bitmap used on the welcome and completion dialogs.
If this variable is set, the installer will replace the default dialog image.
This image must be 493 by 312 pixels.
-
CPACK_WIX_PROGRAM_MENU_FOLDER
¶ Start menu folder name for launcher.
If this variable is not set, it will be initialized with CPACK_PACKAGE_NAME
-
CPACK_WIX_CULTURES
¶ Language(s) of the installer
Languages are compiled into the WixUI extension library. To use them, simply provide the name of the culture. If you specify more than one culture identifier in a comma or semicolon delimited list, the first one that is found will be used. You can find a list of supported languages at: http://wix.sourceforge.net/manual-wix3/WixUI_localization.htm
-
CPACK_WIX_TEMPLATE
¶ Template file for WiX generation
If this variable is set, the specified template will be used to generate the WiX wxs file. This should be used if further customization of the output is required.
If this variable is not set, the default MSI template included with CMake will be used.
-
CPACK_WIX_PATCH_FILE
¶ Optional list of XML files with fragments to be inserted into generated WiX sources
This optional variable can be used to specify an XML file that the WIX generator will use to inject fragments into its generated source files.
Patch files understood by the CPack WIX generator roughly follow this RELAX NG compact schema:
start = CPackWiXPatch CPackWiXPatch = element CPackWiXPatch { CPackWiXFragment* } CPackWiXFragment = element CPackWiXFragment { attribute Id { string }, fragmentContent* } fragmentContent = element * - CPackWiXFragment { (attribute * { text } | text | fragmentContent)* }
Currently fragments can be injected into most Component, File, Directory and Feature elements.
The following additional special Ids can be used:
#PRODUCT
for the<Product>
element.#PRODUCTFEATURE
for the root<Feature>
element.
The following example illustrates how this works.
Given that the WIX generator creates the following XML element:
<Component Id="CM_CP_applications.bin.my_libapp.exe" Guid="*"/>
The following XML patch file may be used to inject an Environment element into it:
<CPackWiXPatch> <CPackWiXFragment Id="CM_CP_applications.bin.my_libapp.exe"> <Environment Id="MyEnvironment" Action="set" Name="MyVariableName" Value="MyVariableValue"/> </CPackWiXFragment> </CPackWiXPatch>
-
CPACK_WIX_EXTRA_SOURCES
¶ Extra WiX source files
This variable provides an optional list of extra WiX source files (.wxs) that should be compiled and linked. The full path to source files is required.
-
CPACK_WIX_EXTRA_OBJECTS
¶ Extra WiX object files or libraries
This variable provides an optional list of extra WiX object (.wixobj) and/or WiX library (.wixlib) files. The full path to objects and libraries is required.
-
CPACK_WIX_EXTENSIONS
¶ This variable provides a list of additional extensions for the WiX tools light and candle.
-
CPACK_WIX_<TOOL>_EXTENSIONS
¶ This is the tool specific version of CPACK_WIX_EXTENSIONS.
<TOOL>
can be either LIGHT or CANDLE.
-
CPACK_WIX_<TOOL>_EXTRA_FLAGS
¶ This list variable allows you to pass additional flags to the WiX tool
<TOOL>
.Use it at your own risk. Future versions of CPack may generate flags which may be in conflict with your own flags.
<TOOL>
can be either LIGHT or CANDLE.
-
CPACK_WIX_CMAKE_PACKAGE_REGISTRY
¶ If this variable is set the generated installer will create an entry in the windows registry key
HKEY_LOCAL_MACHINE\Software\Kitware\CMake\Packages\<PackageName>
The value for<PackageName>
is provided by this variable.Assuming you also install a CMake configuration file this will allow other CMake projects to find your package with the
find_package()
command.
-
CPACK_WIX_PROPERTY_<PROPERTY>
¶ This variable can be used to provide a value for the Windows Installer property
<PROPERTY>
The following list contains some example properties that can be used to customize information under “Programs and Features” (also known as “Add or Remove Programs”)
- ARPCOMMENTS - Comments
- ARPHELPLINK - Help and support information URL
- ARPURLINFOABOUT - General information URL
- ARPURLUPDATEINFO - Update information URL
- ARPHELPTELEPHONE - Help and support telephone number
- ARPSIZE - Size (in kilobytes) of the application
-
CPACK_WIX_ROOT_FEATURE_TITLE
¶ Sets the name of the root install feature in the WIX installer. Same as CPACK_COMPONENT_<compName>_DISPLAY_NAME for components.
-
CPACK_WIX_ROOT_FEATURE_DESCRIPTION
¶ Sets the description of the root install feature in the WIX installer. Same as CPACK_COMPONENT_<compName>_DESCRIPTION for components.
-
CPACK_WIX_SKIP_PROGRAM_FOLDER
¶ If this variable is set to true, the default install location of the generated package will be CPACK_PACKAGE_INSTALL_DIRECTORY directly. The install location will not be located relatively below ProgramFiles or ProgramFiles64.
Note
Installers created with this feature do not take differences between the system on which the installer is created and the system on which the installer might be used into account.
It is therefore possible that the installer e.g. might try to install onto a drive that is unavailable or unintended or a path that does not follow the localization or convention of the system on which the installation is performed.
-
CPACK_WIX_ROOT_FOLDER_ID
¶ This variable allows specification of a custom root folder ID. The generator specific
<64>
token can be used for folder IDs that come in 32-bit and 64-bit variants. In 32-bit builds the token will expand empty while in 64-bit builds it will expand to64
.When unset generated installers will default installing to
ProgramFiles<64>Folder
.
-
CPACK_WIX_ROOT
¶ This variable can optionally be set to the root directory of a custom WiX Toolset installation.
When unspecified CPack will try to locate a WiX Toolset installation via the
WIX
environment variable instead.


Top 10 free things to do in New York
Central Park, Brooklyn Bridge, the High Line… some of New York's most famous attractions don't cost a dime. We pick the best, plus where to head for free concerts, beer and comedy in the Big Apple
@(message: String)


| Module | ActionView::Helpers::PrototypeHelper |
| In: |
/usr/lib/ruby/gems/1.8/gems/actionpack-3.0.0.beta4/lib/action_view/helpers/scriptaculous_helper.rb
/usr/lib/ruby/gems/1.8/gems/actionpack-3.0.0.beta4/lib/action_view/helpers/prototype_helper.rb |
Prototype is a JavaScript library that provides DOM manipulation, Ajax functionality, and more traditional object-oriented facilities for JavaScript. This module provides a set of helpers to make it more convenient to call functions from Prototype using Rails, including functionality to call remote Rails methods (that is, making a background request to a Rails action) using Ajax. This means that you can call actions in your controllers without reloading the page, but still update certain parts of it using injections into the DOM. A common use case is having a form that adds a new element to a list without reloading the page or updating a shopping cart total when a new item is added.
To be able to use these helpers, you must first include the Prototype JavaScript framework in your pages.
javascript_include_tag 'prototype'
(See the documentation for ActionView::Helpers::JavaScriptHelper for more information on including this and other JavaScript files in your Rails templates.)
Now you‘re ready to call a remote action either through a link…
link_to_remote "Add to cart", :url => { :action => "add", :id => product.id }, :update => { :success => "cart", :failure => "error" }
…through a form…
<%= form_remote_tag :url => '/shipping' do -%>
<%= submit_tag 'Recalculate Shipping' %>
 <% end -%>
As you can see, there are numerous ways to use Prototype‘s Ajax functions (and actually more than are listed here); check out the documentation for each method to find out more about its usage and options.
See link_to_remote for documentation of options common to all Ajax helpers; any of the options specified by link_to_remote can be used by the other helpers.
When building your action handlers (that is, the Rails actions that receive your background requests), it‘s important to remember a few things. First, whatever your action would normally return to the browser, it will return to the Ajax call. As such, you typically don‘t want to render with a layout. This call will cause the layout to be transmitted back to your page, and, if you have a full HTML/CSS, will likely mess a lot of things up. You can turn the layout off on particular actions by doing the following:
class SiteController < ActionController::Base layout "standard", :except => [:ajax_method, :more_ajax, :another_ajax] end
Optionally, you could do this in the method you wish to lack a layout:
render :layout => false
You can tell the type of request from within your action using the request.xhr? (XmlHttpRequest, the method that Ajax uses to make background requests) method.
def name # Is this an XmlHttpRequest request? if (request.xhr?) render :text => @name.to_s else # No? Then render an action. render :action => 'view_attribute', :attr => @name end end
The else clause can be left off and the current action will render with full layout and template. An extension to this solution was posted to Ryan Heneise‘s blog at ArtOfMission.
layout proc{ |c| c.request.xhr? ? false : "application" }
Dropping this in your ApplicationController turns the layout off for every request that is an "xhr" request.
If you are just returning a little data or don‘t want to build a template for your output, you may opt to simply render text output, like this:
render :text => 'Return this from my method!'
Since whatever the method returns is injected into the DOM, this will simply inject some text (or HTML, if you tell it to). This is usually how small updates, such updating a cart total or a file count, are handled.
See JavaScriptGenerator for information on updating multiple elements on the page in an Ajax response.
| CALLBACKS | = | Set.new([ :create, :uninitialized, :loading, :loaded, :interactive, :complete, :failure, :success ] + (100..599).to_a) |
| AJAX_OPTIONS | = | Set.new([ :before, :after, :condition, :url, :asynchronous, :method, :insertion, :position, :form, :with, :update, :script, :type ]).merge(CALLBACKS) |
Returns the JavaScript needed for a remote function. Takes the same arguments as link_to_remote.
Example:
# Generates: <select id="options" onchange="new Ajax.Updater('options', # '/testing/update_options', {asynchronous:true, evalScripts:true})"> <select id="options" onchange="<%= remote_function(:update => "options", :url => { :action => :update_options }) %>"> <option value="0">Hello</option> <option value="1">World</option> </select>
# File /usr/lib/ruby/gems/1.8/gems/actionpack-3.0.0.beta4/lib/action_view/helpers/prototype_helper.rb, line 117 117: def remote_function(options) 118: javascript_options = options_for_ajax(options) 119: 120: update = '' 121: if options[:update] && options[:update].is_a?(Hash) 122: update = [] 123: update << "success:'#{options[:update][:success]}'" if options[:update][:success] 124: update << "failure:'#{options[:update][:failure]}'" if options[:update][:failure] 125: update = '{' + update.join(',') + '}' 126: elsif options[:update] 127: update << "'#{options[:update]}'" 128: end 129: 130: function = update.empty? ? 131: "new Ajax.Request(" : 132: "new Ajax.Updater(#{update}, " 133: 134: url_options = options[:url] 135: url_options = url_options.merge(:escape => false) if url_options.is_a?(Hash) 136: function << "'#{escape_javascript(url_for(url_options))}'" 137: function << ", #{javascript_options})" 138: 139: function = "#{options[:before]}; #{function}" if options[:before] 140: function = "#{function}; #{options[:after]}" if options[:after] 141: function = "if (#{options[:condition]}) { #{function}; }" if options[:condition] 142: function = "if (confirm('#{escape_javascript(options[:confirm])}')) { #{function}; }" if options[:confirm] 143: 144: return function 145: end
Yields a JavaScriptGenerator and returns the generated JavaScript code. Use this to update multiple elements on a page in an Ajax response. See JavaScriptGenerator for more information.
Example:
update_page do |page| page.hide 'spinner' end
# File /usr/lib/ruby/gems/1.8/gems/actionpack-3.0.0.beta4/lib/action_view/helpers/prototype_helper.rb, line 583 583: def update_page(&block) 584: JavaScriptGenerator.new(view_context, &block).to_s.html_safe 585: end
Works like update_page but wraps the generated JavaScript in a


Class: Sketchup::ModelObserver Abstract
| Relationships | |
| Inherits: | Object |
Overview
To implement this observer, create a Ruby class of this type, override the desired methods, and add an instance of the observer to the model.
This observer interface is implemented to react to model events.
Note that the observers related to transactions (aka undoable operations) are primarily for reporting and debugging. Performing any edit operations of your own (such as modifying the model) inside the observer callback should be avoided, as it could cause crashes or model corruption. The most common use for these callbacks is to help debug problems where your Ruby script’s Model#start_operation and Model#commit_operation calls are somehow conflicting with SketchUp’s native undo operations. You can set up an observer set to watch precisely what is going on.
Instance Method Summary
-
#onActivePathChanged(model) ⇒ nil
The #onActivePathChanged method is invoked when the user opens or closes a
ComponentInstance
orGroup
for editing. -
#onAfterComponentSaveAs(model) ⇒ nil
The #onAfterComponentSaveAs method is invoked when the user context-clicks > Save As on a component instance.
-
#onBeforeComponentSaveAs(model) ⇒ nil
The #onBeforeComponentSaveAs method is invoked when the user context-clicks > Save As on a component instance.
-
#onDeleteModel(model) ⇒ nil
The #onDeleteModel method is invoked when a model is deleted.
-
#onEraseAll(model) ⇒ nil
The #onEraseAll method is invoked when everything in a model is erased.
-
#onExplode(model) ⇒ nil
The method is invoked whenever a component anywhere in this model is exploded.
-
#onPidChanged(model, old_pid, new_pid) ⇒ nil
The #onPidChanged method is invoked when a persistent id in the model changes.
-
#onPlaceComponent(model) ⇒ nil
The #onPlaceComponent method is invoked when a component is “placed” into the model, meaning it is dragged from the Component Browser.
-
#onPostSaveModel(model) ⇒ nil
The #onPostSaveModel method is invoked after a model has been saved to disk.
-
#onPreSaveModel(model) ⇒ nil
The #onPreSaveModel method is invoked before a model is saved to disk.
-
#onSaveModel(model) ⇒ nil
The #onSaveModel method is invoked after a model has been saved to disk.
-
#onTransactionAbort(model) ⇒ nil
The #onTransactionAbort method is invoked when a transaction is aborted.
-
#onTransactionCommit(model) ⇒ nil
The #onTransactionCommit method is invoked when a transaction is completed.
-
#onTransactionEmpty(model) ⇒ nil
The #onTransactionEmpty method is invoked when a transaction (aka an undoable operation) starts and then is committed without anything being altered in between.
-
#onTransactionRedo(model) ⇒ nil
The #onTransactionRedo method is invoked when the user “redoes” a transaction (aka undo operation.) You can programmatically fire a redo by calling Sketchup.sendAction(“editRedo”).
-
#onTransactionStart(model) ⇒ nil
The #onTransactionStart method is invoked when a transaction (aka an undoable operation) starts.
-
#onTransactionUndo(model) ⇒ nil
The method is invoked when the user “undoes” a transaction (aka undo operation.) You can programmatically fire an undo by calling Sketchup.sendAction(“editUndo”).
Instance Method Details
#onActivePathChanged(model) ⇒ nil
The #onActivePathChanged
method is invoked when the user opens or closes a ComponentInstance
or Group
for editing.
When the user opens an instance for editing the positions and transformations of the entities in the opened instance will be relative to global world coordinates instead of the local coordinates relative to their parent.
See Model#active_path and Model#edit_transform for methods that report the current edit origin vs. the global origin, etc.
By using this observer callback, you can keep track of the various nested transformations as your users double click to drill into and out of component edits.
#onAfterComponentSaveAs(model) ⇒ nil
The #onAfterComponentSaveAs
method is invoked when the user context-clicks > Save As on a component instance. It is called just after the component is written to disk, so you can restore the component to some state before returning control to the user.
#onBeforeComponentSaveAs(model) ⇒ nil
The #onBeforeComponentSaveAs
method is invoked when the user context-clicks > Save As on a component instance. It is called just before the component is written to disk, so you can make changes within the handler and it will make it into the save.
For example, you may decide that you want to add some attribute to every component that is saved out, but you do not want that attribute sticking around inside the current model. Within #onBeforeComponentSaveAs
you could add the attribute, and within #onAfterComponentSaveAs you could delete that attribute.
The callback is not sent the component that is to be saved, but the model’s selection will contain it.
#onDeleteModel(model) ⇒ nil
The #onDeleteModel
method is invoked when a model is deleted.
#onEraseAll(model) ⇒ nil
The #onEraseAll
method is invoked when everything in a model is erased.
#onExplode(model) ⇒ nil
The #onExplode
is invoked whenever a component anywhere in this model is exploded. This is an easier way to watch explode events vs. attaching an InstanceObserver
to every instance in the model.
Since the callback does not return what was exploded, one solution is to place a selection observer that keeps track of which entities whose explosion you are interested in are in the selection. Since SketchUp’s user interface only provides a means of exploding the selection, this method is a reliable way to know what was just exploded.
Another method would be to watch Sketchup::ComponentDefinition.count_instances
to determine what just changed, as any components that were exploded will now be less an instance.
#onPidChanged(model, old_pid, new_pid) ⇒ nil
The #onPidChanged
method is invoked when a persistent id in the model changes. For example when entities are grouped.
#onPlaceComponent(model) ⇒ nil
The #onPlaceComponent
method is invoked when a component is “placed” into the model, meaning it is dragged from the Component Browser.
#onPostSaveModel(model) ⇒ nil
The #onPostSaveModel
method is invoked after a model has been saved to disk.
#onPreSaveModel(model) ⇒ nil
The #onPreSaveModel
method is invoked before a model is saved to disk.
#onSaveModel(model) ⇒ nil
The #onSaveModel
method is invoked after a model has been saved to disk.
#onTransactionAbort(model) ⇒ nil
The #onTransactionAbort
method is invoked when a transaction is aborted.
#onTransactionCommit(model) ⇒ nil
The #onTransactionCommit
method is invoked when a transaction is completed.
#onTransactionEmpty(model) ⇒ nil
The #onTransactionEmpty
method is invoked when a transaction (aka an undoable operation) starts and then is committed without anything being altered in between.
#onTransactionRedo(model) ⇒ nil
The #onTransactionRedo
method is invoked when the user “redoes” a transaction (aka undo operation.) You can programmatically fire a redo by calling Sketchup.sendAction(“editRedo”).
#onTransactionStart(model) ⇒ nil
The #onTransactionStart
method is invoked when a transaction (aka an undoable operation) starts.
#onTransactionUndo(model) ⇒ nil
The #onTransactionUndo
is invoked when the user “undoes” a transaction (aka undo operation.) You can programmatically fire an undo by calling Sketchup.sendAction(“editUndo”).