The Trunk: Tools-eem.754.mcz

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

The Trunk: Tools-eem.754.mcz

commits-2
Eliot Miranda uploaded a new version of Tools to project The Trunk:
http://source.squeak.org/trunk/Tools-eem.754.mcz

==================== Summary ====================

Name: Tools-eem.754
Author: eem
Time: 30 March 2017, 6:07:58.127843 pm
UUID: 961c220b-163f-4034-92c6-2ce4faec8d06
Ancestors: Tools-eem.753

Replace mention of MethodContext with Context in class comments as appropriate.

=============== Diff against Tools-eem.753 ===============

Item was changed:
  Inspector subclass: #ContextVariablesInspector
  instanceVariableNames: 'fieldList'
  classVariableNames: ''
  poolDictionaries: ''
  category: 'Tools-Debugger'!
 
+ !ContextVariablesInspector commentStamp: 'eem 3/30/2017 17:32' prior: 0!
+ I represent a query path into the internal representation of a Context. Typically this is a context at a point in the query path of a Debugger. As a StringHolder, the string I represent is the value of the currently selected variable of the observed temporary variable of the context.!
- !ContextVariablesInspector commentStamp: '<historical>' prior: 0!
- I represent a query path into the internal representation of a ContextPart. Typically this is a context at a point in the query path of a Debugger. As a StringHolder, the string I represent is the value of the currently selected variable of the observed temporary variable of the context.!

Item was changed:
  FileList subclass: #PluggableFileList
  instanceVariableNames: 'accepted fileFilterBlock canAcceptBlock validateBlock newFiles prompt resultBlock'
  classVariableNames: ''
  poolDictionaries: ''
  category: 'Tools-FileList'!
 
+ !PluggableFileList commentStamp: 'eem 3/30/2017 17:30' prior: 0!
- !PluggableFileList commentStamp: '<historical>' prior: 0!
  I am a model for a modal dialog akin to "Standard File Services" on various modern GUI operating systems.  My protocol includes some methods to maintain upward compatibility with StandardFileMenu, which I hope to replace.
 
  Sample doIts:
 
  "StandardFileDialog getFolder"-- ask user to select folder, answer corresponding FileDirectory
  "StandardFileDialog getFile" -- ask user to select file, answer corresponding FileStream
  "StandardFileDialog putFile" -- ask user to create new file, answer FileStream
 
    In addition to the instance variables inhereted from FileList, of which I am a subclass, I am pluggable via the following instance variables:
 
  prompt <String>
  Display a prompt between the buttons.
 
+ resultBlock <BlockClosure>
- resultBlock <BlockContext>
  Passed a file directory and a file name, answer the result to be answered by the dialog.
 
+ canAcceptBlock <BlockClosure>
- canAcceptBlock <BlockContext>
  Answer whether the accept button should be "active"
 
+ fileFilterBlock <BlockClosure>
- fileFilterBlock <BlockContext>
  Passed a file directory entry, answer whether the entry should be added to the list.  The list can be further filtered (but not expanded) by the user through the pattern.
 
+ validateBlock <BlockClosure>
- validateBlock <BlockContent>
  Passed a file directory entry, a file name and a collection of newly created files, answer whether the dialog selection is valid.  validateBlock is checked after the user has pressed accept, for example to ask if the user really meant to delete a file.
 
  newFiles <OrderedCollection>
 
  newFiles is an OrderedCollection of fileNames of files added by the user to the current directory since the user last entered same!