-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Freeze header row functionality #169
Conversation
Fail first
multiple rows may be frozen using this method. Function to unfreeze rows also required
Using adequate JS object accessors
This will reset hands on table fixed Row variable and remove any frozen rows from the UI
Uncertain what the issue is here but messages not being sent to enable user to use Main process menu for freezing/unfreezing rows
for fix to #148 sans the header-dialect functionality |
Really quick off-the-cuff response. I've not checked out the code and run it, but I think the piece of the jigsaw you are missing is that you haven't defined handlers for the If you add a few lines to https://github.com/theodi/comma-chameleon/blob/master/renderer/index.js declaring handlers like
..that should get you moving :) |
Thank you for the pointer @chris48s , still reacclimatising to Electron environment, that's unblocked it! |
This is basically the bare bones functionality to freeze the header. What could be improved in subsequent patches are...
Additions suffice to add mvp user functionality |
This seems to behave differently depending on whether you drag a selection down from the top or up from the bottom. For example, here I've dragged the selection down from the top: I'd expect that to freeze the top 4 rows, but it does nothing. I see that is because the 'selected' cell is in the top row, but I think this is still a bit counter-intuitive (is this just me that expects this behaviour?). Would an easier way to make this clearer be to only work with a single row selection? If others think the behaviour I'm expecting here is strange, feel free to ignore this point. Also sometimes it freezes just the row numbers, not the whole row, like this: .. but I can't quite work out the steps to reproduce that. I would expect that to do this: Also a few more minor observations:
|
Rather than enabling user to freeze multiple rows this change stipulates that only the header row may be frozen. I reason this is consistent with Comma Chameleon as constrained editor design principle (in addition to being more straightforward). Calling updateSettings() twice is a hack but is required due to how the render callbacks execute. The second call could be used to set `colHeaders` to false, enabling the user to use their header row as GUI headers
@chris48s I made the suggestions, with more detail here. |
}, | ||
afterLoadData: function() { | ||
loader.hideLoader(); | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add a handler for the afterUpdateSettings
event here
renderer/index.js
Outdated
@@ -153,3 +153,10 @@ ipc.on('removeRows', function() { | |||
ipc.on('removeColumns', function() { | |||
hotController.removeColumns(); | |||
}); | |||
|
|||
ipc.on('freezeRows', function(){ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This event hander should be updated to expect an event called 'freeze'
to match with the event you're raising here
renderer/menu.js
Outdated
}); | ||
|
||
var unfreezeRow = new MenuItem({ | ||
label: 'unfreeze header row', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
'Unfreeze Header Row'
Managed to slot in a bit of time to look at this tonight for you. All the odd behaviours I reported in my previous post seem to be fixed now, so that's useful. There's one minor problem: The right-click menu item works but the 'Freeze Header Row' in the Edit menu item doesn't. It is firing an event called
Yeah - I can see the issue you were having. I'm also not entirely sure if this is intended behaviour for HoT or a bug we need to work around, but I think there is a neater way to ensure the re-rendering occurs after the setting are applied. Define a
I've also added a line note where that declaration should live. Then that allows you to simplify your event handlers to:
and deal with the cleanup in the handler function (which is guaranteed to execute after the settings have been applied). Maybe also note in issue #159 that we might be able to remove that manual call to |
Hey @chris48s , thanks so much for taking the time to give me solid |
no probs - glad to help :) |
Cool, so I'm taking your input as a code review @chris48s and I'm going to merge this in now |
opening a PR to see if I am on the right path with this or in case I'm missing an easy trick.
I have made the minimum changes required to freeze a row for scrolling purposes. I've left it open for a user to freeze multiple rows even though a CSV headers approach would prefer for this not to be the case.
As far as I can tell Electron doesn't support dynamics changes to menu items which would fit with a toggled 'freeze row / unfreeze row' addition to both menu items.
@chris48s I'm blocked on the inclusion of these functions in the
main
process menu. Basically it seems like nothing is firing betweenmain
andrenderer
. Was wondering if you could take a glance at the code and tell me if I am doing anything glaringly wrong or if there is a better way of writing code the communicates between the main and renderer process in Electron nowadays