to get the table 1 to select the correct row after adding rows to table two.
If it can work in a non buggy way it will be good. I still prefer using the classes I have set up for handling the array controllers since it is very solid and requires no workarounds.
Yet if this can work, it will be a nice simple solution, especially for those with no OBJ-C in their proj.
property theData:missing value
on addSet_(sender)
set my theData to my theData & {{backupset:"newBackupset", sourcefiles:{{fileicon:"",sourcefile:"somefile", filesize:"---"}}}}
end addSet_
on awakeFromNib()
set my theData to {{backupset:"newBackupset", sourcefiles:{{fileicon:"a", sourcefile:"somefile", filesize:"---"}}}, {backupset:"newBackupset", sourcefiles:{{fileicon:"b", sourcefile:"anothersomefile", filesize:"---"}}}}
end awakeFromNib
for the add and the built in “remove” connected through IB.
I started fresh again and copied exactly all the same settings you had in the sample and went back to just one table and it does the same thing: When you edit rows and then do “remove”, the rows return to their original values. It seems better than before otherwsie. Worse trouble begins when I hook up the second table.
I just downloaded a fresh copy of your florida app and it does the same thing!
Edit some of the names and then try to delete a row. The values go back to the original values. Oddly the last time I tried this with your app it seemed to retain values…
The two tables are now in sync without any weird behavior. I had to mess around with the array controller settings for the bindings and the attributes to get it right. I’ll post the result if it all looks good tomorrow.
Thanks Shane. If this works it will have saved me many lines of code.
I was using “my thedata” referring to the variable bound to the array controllers content. I tried setting theOriginalData to my theData and did the changes to that and then set my theData back to theOriginalData at the end. It seemed to work better that way. I tried both ways.
But using soucrefiles:“” and then trying to set soucrefiles in table 2 causes the all the sets in table 1 to also have added that record. You will see if you try it out.
Here is the project if you, or anyone else, wants to give it a try. It is just two tables that are bound. I commented out the “good” code if you want to see how it can run perfectly you can reconstitute the good code. As is - I set it up for allowing an empty table 2 which is what I am struggling with here.
OK, you need to use sourcefiles:{} in each instance.
And you can also skip using theOriginalData if you follow up changes to theData like this:
if bTableView's numberOfRows() = 0 then
set sourcefiles of item actualSelectedRow of my theData to {{filename:"somefile", filePath:"pathtofile"}}
set my theData to my theData -- registers change
In fact, this lets you do away with that whole test, replaced by:
set end of sourcefiles of item actualSelectedRow of my theData to {filename:"somefile", filePath:"pathtofile"}
set my theData to my theData
You can also set the selection in table 1 like this:
set x to current application's class "NSIndexSet"'s indexSetWithIndex_(setSelection)
aTableView's selectRowIndexes_byExtendingSelection_(x, false)
Hmmm, doing it that way you also need to trap for for when there’s no selection in table 1 and someone hits Add for table 2. So maybe:
if actualSelectedRow > 0 then
set end of sourcefiles of item actualSelectedRow of my theData to {filename:"somefile", filePath:"pathtofile"}
set my theData to my theData
set x to current application's class "NSIndexSet"'s |indexSetWithIndex_|(setSelection)
aTableView's selectRowIndexes_byExtendingSelection_(x, false)
end if
And you need to capitalize the “P” in filePath in your binding of the second column of the second table.
Brilliant. I knew there must be a way to place that more simply.
I actually tried “set my theData to my theData” to see if it would give everything a kick but no luck. But other things were off.
I looked up NSIndexSet and got scared - I had been doing pretty well with OBJ-C and Cocoa stuff till then.
I never would have seen that! One of the major mistakes I keep making is with punctuation. But you know- my applescript could get pretty sloppy with naming conventions and ASOC is forcing me to clean up my act.
A good lesson here; you can try things that will work along the way but you need to know why they are right to write code well.
I got burned out with bindings and lost my way, and missed some crucial things. You have been a great help Shane - thanks.
And this does show the really good possibilities with ASOC going forward- so much less code! I will put together the Two tables as an example project.
When you delete the last row in table 2, you can no longer add a new row. This one seems trickier since the remove call is built and we have no control over it. I’ll ponder this… perhaps a manual remove handler instead.
Yes, it looks like I was being too smart with “set end…” – the remove is change a list of lists to a simple list. Change back to this:
set sourcefiles of item actualSelectedRow of my theData to {{filename:"somefile", filePath:"pathtofile"}} & sourcefiles of item actualSelectedRow of my theData
It works because of the extra “set my theData to my theData” line.
It’s been a bit of a battle, and you can see why bindings have a reputation for being fiddly. But even if you’d just used them to supply the data, and did the adding and deleting by code, I reckon they still beat fiddling with data sources and table delegates. And some people are happy with just one table