Newsgroup: it.comp.lang.vo-clipper
Titolo: Edit Change per Check Box

Il metodo EditChange mi sembra che non rilevi i cambiamenti di stato delle
Check Box. Qualche persona gentile mi potrebbe indicare come fare per
rilevare il cambiamento di stato delle Check Box durante l'editing della
data window?
Ciao a tutti. Ci vediamo domani a Milano?
Roberto Cordini
Scusate se questo messaggio comparirà più volte, ma ultimamente ho dei problemi
con outlook e non riesco a leggere i messaggi.
-- 
Posted from 
anb.dsnet.it
 [195.250.243.70] 
via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 ha scritto nel messaggio
news:dfbc287fbd812270b38...@mygate.mailgate.org...


 
buttonclick .... era cosě semplice :-(
Un umile Ciao.
Roberto


 data window?
Ricordatevi che io rispondo sempre in senso generale, dal punto di vista
quindi delle API di Windows, dato che non uso VO.
Esiste il messaggio di notifica chiamato BN_CLICKED che viene inviato da
tutti i pulsanti alla finestra che li contiene, quindi anche dal
checkbox che è un particolare tipo di pulsante. Può darsi che il tuo
strumento gestisca un evento chiamato Click o qualcosa del genere.
EMG
-----------------------------------
EMAG Software homepage
http://www.emagsoftware.it
The EMG's ZX-Spectrum Software Page
http://www.emagsoftware.it/spectrum
The Best of Spectrum Games
http://www.emagsoftware.it/tbosg

 
Prova ad usare questo metodo (se usi VO2.0)
METHOD ButtonClick(oControlEvent) CLASS WinMia
	LOCAL oControl AS Control
	oControl := IIf(oControlEvent == NULL_OBJECT, NULL_OBJECT, 
oControlEvent:Control)
	SUPER:ButtonClick(oControlEvent)
 
	IF (oControlEvent:NameSym == #RadioButton1 .or. oControlEvent:NameSym == 
#RadioButton2 .or. oControlEvent:NameSym == #RadioButton3 .or. 
oControlEvent:NameSym == #RadioButton4)
		// inserisci il codice tuo o richiama un'altro metodo o funzione
		SELF:FunzionePerFareQuelloCheVuoi()
	ENDIF
	RETURN NIL

Scusatemi ho mandato per sbaglio il msg. doppio.... :-)

 
Prova ad usare questo metodo (se usi VO2.0)
METHOD ButtonClick(oControlEvent) CLASS WinMia
LOCAL oControl AS Control
oControl := IIf(oControlEvent == NULL_OBJECT, NULL_OBJECT, 
oControlEvent:Control)
SUPER:ButtonClick(oControlEvent)
 
IF (oControlEvent:NameSym == #RadioButton1 .or. oControlEvent:NameSym == 
#RadioButton2 .or. oControlEvent:NameSym == #RadioButton3 .or. 


Scusatemi ho mandato per sbaglio il msg. doppio.... :-)
E per di piu' il tuo sorgente fa riferimento a un radiobutton invece
che a un checkbox ;-)
Ignazio GSS©
More than 90 HiRes images in my home page  
http://www.geocities.com/~puddu/
Oltre 200 Immagini di endoscopia digestiva
http://www.areamedica.com

data window?
METHOD ButtonClick(oControlEvent) CLASS TuaFinestra
	LOCAL oControl AS Control
	oControl := IIf(oControlEvent == NULL_OBJECT, NULL_OBJECT,
oControlEvent:Control)
	SUPER:ButtonClick(oControlEvent)
	//Put your changes here
	DO CASE
	CASE oControl:NameSym==#TuoControllo
		IF oDcTuocontrollo:checked
			// Fai quel che ti pare
		ELSE
			// Comportati di conseguenza
		ENDIF
	CASE oControl:NameSym==#AltroControllo
		IF oDcAltroControllo:checked
			// ecc. ecc.
		ELSE
			// Idem
		ENDIF
	ENDCASE
	RETURN NIL


 METHOD ButtonClick(oControlEvent) CLASS TuaFinestra
Scusa, non è per fare polemica (ormai mi avete fatto venire una
psicosi...) ma solo per informazione (ed eventuale critica :-) ): ma
TuaFinestra è una classe o un'istanza? Scritto così verrebbe naturale
pensare che si stia definendo una nuova classe chiamata TuaFinestra
(della quale verranno istanziati poi uno o più esemplari all'occorrenza)
e, nello specifico, un metodo di questa classe chiamato ButtonClick().
Ma se è così allora non si capisce come faccia una classe a risolvere i
problemi di una singola istanza. Mi spiego meglio: se in una particolare
finestra io devo fare in modo che clickando su di un checkbox succeda
qualcosa, come può questo essere un comportamento abbastanza generale
(dato che una finestra potrebbe anche non avere checkbox o averne più di
uno) da giustificare la creazione di una classe, per di più neanche
derivata da una classe base (almeno non mi sembra di scorgere
derivazioni nella sintassi esposta)?


derivazioni nella sintassi esposta)?
Non potevo mettere tutto il sorgente, anche perche' tutto il resto lui
lo aveva gia', e io non posso certo sapere che finestra ha creato. :-)
Spero che quanto ho scritto sopra ti abbia chiarito come funziona la
cosa. Per maggiore chiarezza ti mando la descrizione della classe
Datawindow con le sue proprieta' e metodi (poi ci sono i metodi delle
classi genitrici).
Purpose
Create a data window which is capable of interacting intelligently
with a data server.
Class
CLASS DataWindow INHERIT ChildAppWindow
Properties
AllowServerClose Assign
AutoScroll Access/Assign
Background Assign
Browser Access/Assign
BrowserClass Access/Assign
ClipperKeys Access/Assign
ConcurrencyControl Access/Assign
CurrentView Access
DeferUSE  Access/Assign
Foreground Access/Assign
Origin Access/Assign
Owner Access
Pointer Access/Assign
PreventAutoLayout Access/Assign
Server Access
Size Access/Assign
Status Access
Methods
Append()
ButtonClick()
Cancel()
CanvasErase()
CheckStatus()
Clear()
ClearRelations()
Close()
Commit()
Copy()
Cut()
Delete()
DeleteValidated()
Destroy()
DisableConditionalControls()
Draw()
EditChange()
EnableConditionalControls()
Error()
Expose()
FieldGet()
FieldPut()
FocusChange()
GoBottom()
GoTo()
GoTop()
HelpRequest()
Hide()
HorizontalScroll()
Init()
InsertObject()
KeyDown()
KeyUp()
LineTo()
Links()
ListBoxClick()
ListBoxSelect()
MouseButtonDoubleClick()
MouseButtonDown()
MouseButtonUp()
MouseDrag()
MouseMove()
MoveTo()
Notify()
OK()
PaintBoundingBox()
Paste()
PasteSpecial()
Prevalidate()
QueryClose()
RegisterConditionalControls()
Repaint()
RepaintBoundingBox()
Resize()
Seek()
SetRelation()
SetSelectiveRelation()
Show()
Skip()
SkipNext()
SkipPrevious()
StatusOK()
TextPrint()
Undo()
UndoAll()
Use()
ValidateRecord()
VerticalScroll()
ViewAs()
ViewForm()
ViewTable()
Inherits From
VObject, EventContext, Window, AppWindow, ChildAppWindow
Inherited By
DataDialog, OLEDataWindow
Library
GUI Classes
Description
Data windows combine the properties and behavior of both child windows
and dialog windows, and add data-aware behavior that enables them to
interact intelligently with data servers.  When connected to a data
server, a data window forms a view of the server that allows for
direct access and manipulation of the server's data.
Adaptive Behavior
Unlike the other types of windows, a data window takes on different
behavior depending on how it is used.  It adapts itself to the demands
placed on it by its owner, behaving differently depending on the
circumstances:
If Owner Is	Data Window Acts Like
ChildAppWindow	Modal DialogWindow
DataWindow	Modal DialogWindow (if no placement is specified) or
nested sub-data window (if placement is specified)
DialogWindow	Modal DialogWindow
ShellWindow	ChildAppWindow
TopAppWindow	Modal DialogWindow
Sub-Data Windows
A data window can be placed on a data window in an owner-child
relationship (similar to other controls like check boxes and radio
buttons).  When a data window is placed on another data window in this
way, it is referred to as a sub-data window.  Note that only a data
window can own a sub-data window because it is the only window type of
window that can deal with data-related events.  
You can create a data window as a sub-data window when the data window
is created.  You can optionally specify a third parameter
(<nResourceID>), indicating that the new data window should be created
as a control on a window by giving its location and size.  When placed
like a control, the data window hides its border decoration and
behaves like a sub-data window.  (If this parameter is omitted, the
data window is created as a modal DialogWindow, not a sub-data
window.)  See DataWindow:Init() for details.
Tip:  Instead of newly creating a data window, you may prefer to use
the Window Editor's Auto Layout feature which — at the touch of a
button — automatically creates controls for every available field in a
data window's associated data server(s).  See "Using the Window
Editor" in the IDE User Guide.
Server Use
A data window is connected to a server with the Use() method.  When
this connection is established, each control on the window is
connected to a field in the data server based on matching names:  a
field named CustName is connected to the control named CustName.  The
control always reflects the current value of the data in the data
server, and assigning a value to a control automatically propagates it
to the server.
Data windows can be associated with data servers in two ways:  in a
single server or dual server (master detail) relationship.
Master-Detail Option
The Master-Detail option allows you to link a window to two data
servers in a master-detail relationship.  In this case, a data window
is created for the master server with a nested sub-data window for the
detail server.
The field list presented is taken from the Master data server.  The
field that you choose is used to perform a SetSelectiveRelation() to
the detail server based on its controlling order.  If you do not
choose a field, the detail window is updated relative to the current
record position in the master window.
Form and Browse View
A data window can take on two different view modes:  form view, which
contains individual controls for the data fields and browse view,
which contains a spreadsheet-like data browser.  The data window can
be initially displayed in either mode, and can be switched to the
other mode at any time (using the DataWindow:ViewAs() method).  Any
data window supports both appearances, although the developer can, of
course, choose not to provide a way to select one mode or the other.
The two view modes provide the same set of facilities:  the same data
linkage facilities, the same display options, the same data
manipulation methods.  From the perspective of the application, a data
window has the same behavior and the same data properties regardless
of view mode.
Resource-Based Layout
The standard way of using a data window is to paint its layout in the
Window Editor.  This produces a resource entity that specifies what
controls the window has, and their locations, sizes, captions, and
accelerators.  It also generates a data window subclass and an Init()
method that associates names and further annotation with each control.
With such a predefined layout, the window is displayed very quickly
and the methods of the window have enough information to act
intelligently.
Auto Layout
A data window can also be created without a resource entity.  In this
case, the layout of controls on the window is automatically generated
when the window is connected to a data server.  After a layout is
automatically generated, the window has exactly the same behavior that
it has with a resource-based instantiation.
If a data window is switched over to a new view mode, and the new mode
has not been defined through a resource entity or programmatically,
the data window automatically creates a layout based on the
characteristics of the connected data server.  The new layout picks up
all information about fields and controls that is known to the other
view; thus, if complex validation rules, prompts, and help have been
specified for the individual controls in form view, the columns of the
browse view inherit the same properties.
Data Propagation
When a control is connected to a field in a data server, a value
entered into the control or assigned to the appropriate name from the
program is automatically propagated to the server.  Thus, after
executing this statement:
oCustomerWindow:CustName := x
the CustName field in the server has the correct value.
Values are propagated up from the data server to the data window when
the server repositions itself, or when another window makes a change.
This requires no special action: after executing a Skip() method or
assigning a value to a field, every window connected to the server is
automatically updated to reflect the change.
Validation
Data entered by the user is automatically validated using the rules of
the field specification attached to a control or column.  (For more
detail on the validation rules provided, see the FieldSpec class.)  If
data fails the validation test, the data window will not propagate
invalid information down to the server or to other windows, nor will
it take any action that requires writing the invalid value to the
server.
In addition to the field-specific validations, the system allows the
specification of a ValidateRecord() method for the window as a whole,
for the purpose of cross-field validation.  This method, if provided,
is called after all the fields have passed their individual
validations.
The data window also provides for registering controls that are
subject to the validation status.  Such registered controls are
disabled whenever the window's validation status is bad.
Action Methods
The data window class also provides action methods that correspond to
the general capabilities of all data servers: GoTop(), GoTo(),
GoBottom(), SkipNext(), SkipPrevious(), Append(), Delete(), and so on.
The data window versions of these methods verify the validation status
of the controls on the window.  If everything is valid, the window
invokes the corresponding method of the data server.
Concurrency Control
The data window provides built-in facilities for concurrency control,
automatically taking and releasing record locks as appropriate.  Once
the appropriate mode has been selected by assigning one of the
available modes to DataWindow:ConcurrencyControl, record movements and
changes use the concurrency control facilities of the data server to
take and release locks.  If taking a lock fails because another user
controls the record, the data window action fails.


 VObject, EventContext, Window, AppWindow, ChildAppWindow
Ereditarietà multipla? No singola, Ahi, ahi, ahi! :-) A parte gli
scherzi, ancora si discute se l'ereditarietà multipla sia un vantaggio o
rappresenti un grosso problema per la OOP...


 che a un checkbox ;-)
Opsssssss ():-)
 


In VO  è facilmente simulabile l'ereditarietà multipla.
Comunque anche secondo me può creare confusione.
Ciao
      Fabrizio Malaguti


Il motivo che si indica     CLASS TuaFinestra   dopo la dichiarazione di
metodo è per indicare che quel metodo fa parte della classe TuaFinestra ( in
pratica un puntatore alla classe ).
E' proprio questa caratteristica che permette di estendere le funzionalità
della classe di riferimento senza avere i sorgenti; in pratica mi pasta
specificare che quel metodo si riferisce alla classe specificata. Credo che
questa caratteristica sia propria di VO.
Ciao
      Fabrizio Malaguti

 questa caratteristica sia propria di VO.
Non credo che sia vero quello che stai dicendo. O almeno dalla
spiegazione di Ignazio mi era parso di capire qualcosa di molto diverso
(e più corretto): che si stava creando una nuova classe apposta per una
particolare finestra. Insomma, non è proprio il massimo della pulizia ma
certamente mille volte meglio di quello che stai prospettando tu, che io
possa ridefinire i metodi di una classe creata altrove! E poi non
avrebbe senso nello specifico in quanto si parlava di un particolare
comportamento di un checkbox che, ovviamente, non andrebbe bene in altre
finestre.
EMG
EMAG Software Homepage:     
http://www.emagsoftware.it
The EMG's ZX-Spectrum Page: 
http://www.emagsoftware.it/spectrum


possa ridefinire i metodi di una classe creata altrove! E poi non
I metodi della classe non vengono ridefiniti. Semplicemente io creo
una classe Tuafinestra, figlia di DataWindow.
Datawindow ha un metodo che si chiama buttonClick.
Se in Tuafinestra non definisco un metodo ButtonClick se io lo chiamo
verra' eseguito (scusa i termini, ma spero mi si capisca) il Metodo
ButtonClick della classe DATAWINDOW da cui deriva TuaFinestra, ma se
scrivo un metodo ButtonClick CLASS TuaFinestra questo verra' chiamato
(all'interno di Tuafinestra) al posto di quello della DataWindow, ma
il metodo della Datawindow mamma restera' come era, mi sono spiegato?


 E che ha di sporco? :-)
Beh, c'è il problema della proliferazione delle classi. Derivare una
classe per ogni finestra che mi serve nel programma non mi sembra una
buona idea. Forse alcune delle caratteristiche specifiche andrebbero
rappresentate con delle proprietà (dati membro) di una finestra più
generale. Altrimenti sarebbe come se, invece dell'unica classe Fattura,
derivassi da essa le classi FatturaNumero1, FatturaNumero2, etc. invece
di mettere semplicemente l'attributo Numero nella classe Fattura.


di mettere semplicemente l'attributo Numero nella classe Fattura.
Chiarissimo, ma non mi pare che accada.
