I'm using ag-grid and I'd like to save the layout/state of the user. Pretty much something like this
This solution forces the user to click on the button to save the preferences ("Save state"). There is some other way/event to detect that the user changed the state of the table (in order, to me to save and avoid to force the user to click on a button for that)?
I was hopping to find some method here but i didn't..
I initially had code that listened to all of the applicable events from the grid, but ultimately, I found it easier to just save the entire grid state in the component's onDestroy method, regardless of whether anything has actually changed.
Found my answer here.
All the events are here but i prefer to add a global event:
addGlobalListener(listener) Add an event listener for all event types coming from the grid.)
Source: AgGrid javascript grid api
Related
I was wondering how Windows applications typically keep track of dirty controls in a dialog, so that when the user clicks a button like "Apply" or "Save," the application knows which controls' values to commit.
I see that edit controls have an EM_GETMODIFY message, which will tell you whether the contents of the edit control have been modified, but I don't think that type of message is available for other controls like date-time pickers or combo boxes.
So I suspect that this would be done by monitoring change notifications sent from the controls to the parent dialog. But if that's the case, how might the change events be flagged or stored? I thought that perhaps that whenever a change occurs, the application could store the control's ID or hwnd in a std::unordered_set, and then iterate through the set when it's time to commit. Or is there another, more accepted and efficient way? Thank you for any guidance.
I have an MFC MDI application, in which it is possible for documents to have multiple views, and for users to customise and then save layout data for the views. This data is associated with the views, not the documents.
I would like to prompt the users to save if they choose to close a view with unsaved layout changes, and am running into problems, as it seems MFC is only geared towards changes in the document. Here are some approaches I've tried:
Override CDocument::SaveModified function, which gets called by the framework when a document is closed. In this function, I send a message to all the document's views, which can then check for unsaved changes and prompt the user.
Perform the check inside the View's destructor.
Perform the check inside the View's OnClose handler
Each of these approaches has problems. (1) is the best, but it fails to deal with cases where there are several views onto one document, and the user closes one of the views. As the document is still open, SaveModified is not called.
The problem with (2) is that on application shutdown, the application has already disappeard by the time any CView destrutors are called. This can leave an orphan dialog box open on the desktop. This is also the case if I try performing the check inside OnDestroy.
I can't get (3) to work - I can't get my views to respond to WM_CLOSE.
Currently, my best solution is to do both (1) and (2), but this requires some smelly logic to prevent the app from prompting the user to save view changes twice on app shutdown.
Anyone know of a better way of doing this? Where is the correct place to hook in?
I'm not sure if it is your solution, but I have several views that can not close on condition and I handle them in DestroyWindow( ). And a message box there does come up over the app before it closes down. So try using DestroyWindow( ) rather than the destructor.
Concur.
ON_WM_DESTROY()
afx_msg void OnDestroy();
does the trick. It will not prevent the window from closing, but the question didn't request it.
I'm working on a activity diagram that shows model/view transitions. I've done a lot of class diagrams with ArgoUML and want to do this with ArgoUML, too.
For a user input I would usually use an input signal. In ArgoUML 0.34, I can not figure out how signals work. There is no input/output signal component.
How can I show listener events like user input or a model event that leads to an UI update?
It should look like that:
There are a number of elements which are under pulldown menus instead of being directly on the tool bar. The pulldown to the left of the Guard element on the toolbar has all the Events on it. The default tool is the Call Event, but there's a Signal Event underneath as well. Is that what you're looking for?
I have the same question. I've been unable to figure out the correct procedure to model input/output signals in ArgoUML.
I've copied the layout from the original post but wasn't able to change the shape of the symbols:
In the documentation of Ember.StateManager it's said that : "Inside of an action method the given state should delegate goToState calls on its StateManager". Does it mean that if I send an action message, I necessarily need to transit to another state. Is it possible to stay in the same state but doing some task by sending an action ? For example, I'm in a state "loading" and I run two actions "preprocess" and "display".
Very simply: an action message may but does not have to transition to another state.
Something you didn't ask, but is related and important: it is a bad idea and bad design to call goToState in an enter or exit method.
When dealing with statecharts in general, you can do whatever you want. It's not mandatory to switch states in an event handler. A common case would be an event handler that shows a cancel/save dialog. You can easily put the dialog on the page in the event handler, and proceed accordingly depending on which button is pressed.
A separate question is should every event handler basically just go to another state. In the above scenario, you can certainly go to a "confirm" state, the state-enter method will show the dialog, and there would be two handlers, one for each button. Those handler would in turn go to other states.
Both design choices I think are equally valid, at least in that scenario. If you choose to implement a separate state for every action, you will end up with a lot of small but concise states. If you choose to do stuff in the event handlers themselves, your states will be bigger, but there will be less of them.
One thing I will say is if an event handler is getting complicated, you are probably better of with a new state. Also, be consistent.
For you specific scenario, if I'm reading it right, you want to load data and then change the display to show the data, based on an event. In this case, I would use new states.
So you press a button that starts the process
In the event handler, go to some sort of 'MyDataSection' state
Initial substate is 'loadData'
Enter state method of 'loadData' starts the loading process
Event handler 'dataLoaded' in 'loadData' to handle when the data loads; this means you need to fire an event when the data loads
'dataLoaded' event goes to the 'show' state
show state shows the view (or removes activity indicator etc) and handles any events that come from the display.
What's good here is that if you have multiple ways to get to this section of the app, all actions that lead to this section only need to go to this state, and everything will always happen the same. Also note that since the view event handlers are on the show state, if the user hits a button while the data is loading, nothing will happen.
In my game, I have a panelA that has checkboxes to toggle panels in panelA's parent. It also has a Leave button which needs to make a call to the scene manager that only PanelA's parent is aware of.
I've thought of:
Making a listener just for this
Have the parent make the PanelA and make its children so it has
access to them and can receive action events from them
Neither of these feel that clean. Would there be a better way?
My game uses a gui system that I made. Sending events up to the parent wouldn't work because the parent does not know which gui components it's looking to handle.
Thanks
It's a bit hard to know without knowing the design of your system, but basically you don't want to change checkboxes in the panel, but you want to change the state and have those checkboxes reflect the state.
Say you want to check a box for Vertical Blanking in your main-panel. Do do not want to do this
parent->waitForVerticalBlankCheck.Checked=true
instead you want this
renderingConfiguration->isVerticalBlankEnabled=true;
and in your "main panel"
if(renderingConfiguration->isVerticalBlankEnabled)
waitForVerticalBlankCheck.Checked=true;
Uhm.. very pseudocody, but hopefully you get the idea :)