CAsba wrote: ↑Fri Mar 22, 2024 1:29 pm
Code: Select all
on selectionChanged pHilitedIndexes, pPreviouslyHilitedIndexes
if fld "indicator" is 0 then
send "mouseup" to btn "extract" of cd "manage products"#gets data into fields
send "mouseup" to btn "setdg"#shows columns appropriate to one of the fields
put 1 in fld "indicator"
send "selectionChanged pHilitedIndexes, pPreviouslyHilitedIndexes" to grp "database 3"
exit selectionchanged
end if
put fld "fcode" into tNewCost
put the dgHilitedIndex of grp "datagrid 3" into tIndex
put the dgDataOfIndex[tIndex] of grp "datagrid 3" into tArray
put tNewCost into tArray["stock"]
set the dgDataOfIndex[tIndex] of grp "datagrid 3" to tArray
exit selectionchanged
if fld "edit2" is 0 and fld "deleting" is 0 then
send "mouseup" to btn "dgcode" of cd "manage products"
end if
end selectionChanged
As Klaus says the handler will stop executing and exit at line 7 if the first condition is true or at line 16 if not. "exit" should only be used if you
want code execution to stop and putting code after this is nonsensical. Anything after this will not execute if you have reached the "exit handler" line.
My
personal preferences in coding is to parcel out code into handlers in card or stack script so they can be referenced from anywhere, instead of sending mouseUps to buttons. I also prefer to use script local variables instead of fields for true/false flags (which I presume is what the 0 and 1 values refer to). This helps keep code clean, readable and easy to debug.
As already mentioned, there is no need to "put the dghilitedIndex of group DG3" - this
is the pHilitedIndexes in the very first line.
Does the line:
send "selectionChanged pHilitedIndexes, pPreviouslyHilitedIndexes" to grp "database 3" actually do anything?
Either it doesn't (because this is only triggered by user intervention, not by script)
Or it does something because you've put code in "database 3" selectionChanged handler that does something based on the index
But in itself, this will
not hilite the same index and therefore any other code executed is probably better parcelled out into it's own handler that takes the index as a parameter.
Doing the above would make the code in the data grid's script easier to read. Your DG3 script could look exactly like this:
Code: Select all
local sIndicator, sEdit2, sDeleting
on selectionChanged pHilitedIndexes, pPreviouslyHilitedIndexes
if not sIndicator then
extractAndSetDG
put true into sIndicator
dispatch "database3code" to group "database 3" with "pHilitedIndexes"
exit selectionchanged // _ONLY_ if you want the code to stop here
end if
put the dgDataOfIndex[pHilitedIndexes] of grp "datagrid 3" into tArray
put fld "fcode" into tArray["stock"]
set the dgDataOfIndex[pHilitedIndexes] of grp "datagrid 3" to tArray
if not sEdit2 and not sDeleting then dgCode
end selectionChanged
This, for me at least, is much easier to read and debug.
Instead of sending mouseUps to buttons, it refers to handlers in the card script:
Code: Select all
command extractAndSetDG
// do stuff that is currently in btn "extract" and btn "setdg"
end extractAndSetDG
command dgCode
// do stuff that is currently in button "dgCode"
end dgCode
and instead of sending a message that won't actually do much in the group "database 3":
Code: Select all
on database3code
// do stuff that is currently in teh selectionChanged of group "database 3"
end database3code
But each to his own I suppose...
