Using c++ builder borland (bcb6).
I wish to invoke manually button click event. I did:
FMap->bbDoneInClick(NULL);
While Done button located on the FMap form, but something went wrong with that.
Do I need to call bbDoneInClick with different parameters and not with NULL ?
Instead of NULL use the Form1 or the bbDone itself ...
it depends on the event code itself how it uses the Sender parameter
Also you can call the event handler safely only if the form is already created
if it does not access Canvas you can use it even in TForm1::TForm1 constructor
if it does you need to take care of not using it prior to OnShow or OnActivate
to avoid VCL problems or App crashes
for common handlers it is sufficient to use main window ... (I use this instead of NULL)
if you have single even handler for multiple components then the even is usually deciding the operation or target from the Sender parameter so in that case you need to pass the pointer to component itself
Related
TL/DR: React components have two kinds of code:
rendering code that draws the component, which depends on certain props that affect the component's visual appearance (call them "visual props"), and
event-handling code, e.g., onclick handlers, which depends on certain props that don't affect the component's visual appearance (call them "event props").
When event props change, they cause the component to re-render, even though its appearance doesn't change. The only thing changing is its future event-handling behavior.
What's best practice for removing event props to avoid unnecessary re-renders, while still allowing intelligent event handling?
Longer version
My question is subtly different from this question about how to give handlers to dumb React components; see below for explanation.
I have an application with many React components (hundreds to thousands of SVG elements; it's a CAD application).
There are many "edit modes" in this application (imagine a drawing program like Inkscape): depending on the edit mode, you might want a left-click to select an object, or drag to draw a selection outline rectangle, or do any number of different edits to the component that was clicked, depending on the edit mode.
In my original architecture, every one of these components had the current edit mode as a prop. Each component would use the mode prop to decide what to do in response to events such as clicks: different sorts of Redux actions are dispatched in response to clicks depending on the current mode. This means that every time the user switches the edit mode, every component gets re-rendered, even though none of them change visually. In a large design, it takes several seconds to re-render.
I've altered it to improve performance. Now, each component is dumber: none of them know the edit mode. But this means they don't know what to do in response to a click. In some cases, I solved this by having each dispatch a "dumber" action that says essentially "I was clicked". Middleware intercepts this action, looks up the edit mode in the Redux store, and dispatches an appropriate smart action based on the edit mode. In other cases, I simply let the component dispatch the original action (e.g., Select), even if that action may not be valid for the current edit mode, and similarly rely on the middleware to intercept and stop the action if it is invalid for the current edit mode.
This solution feels inelegant. Now, many more actions get dispatched, even though most of them are thrown away. It's also nothing like what I find in introductions/tutorials to middleware, which mostly talk about how it's good for async stuff (I don't need any of this to be asynchronous since these actions generally are not talking to the network or files) and side-effects such as logging (no side-effects here; I simply want a user interaction to trigger a normal Redux action to be dispatched).
I feel as though a better solution would be to access the Redux store as a global variable within event handling code. I know this is emphatically not safe to do with rendering code, since it breaks the rule "React views should be a deterministic function of their props and state". But it feels safer to do with event-handling code.
I realize it's common with "very dumb" React components to pass click handlers in as a prop (e.g., this stackoverflow answer), but I don't see this as a solution. If handler has the edit mode encoded in it as a bound value, then the handler itself needs to change when the edit mode changes, which, since the handler is a prop, requires re-rendering the component. So I think this issue I'm describing is orthogonal to whether the handler is passed into the component as a prop, or written specifically for the component.
So to summarize, there's three options I see:
Pass all data required for intelligent event handling as props. (causes unnecessary re-renders)
Have React components dispatch actions "promiscuously", and rely on middleware (which has access to the Redux store) to stop and/or transform the action if necessary. (As I implemented it, is harder to understand, and puts lots of unrelated application logic in one place, where it feels like it doesn't belong. Also makes for a messier Redux history of actions, making it harder to debug using Redux DevTools, and is not a pattern I've seen in any documentation/tutorial on Redux middleware.)
Allow event handler code (unlike rendering code) to access the Redux store as a global variable, to make intelligent decisions about what action to dispatch. (Seems okay, but scares me to use global variables in this way, and I'm worried that it could cause a problem I'm not seeing.)
Is there a fourth option I'm missing?
I have an idea for how to solve this in a way that feels close to the Redux spirit. (Though I still lean towards accessing global variables in event handlers to solve the problem.)
Redux has some notion of "action creators", which is a function that returns an action object. This always seemed like an unnecessary layer of abstraction to me. But perhaps a similar idea can be used here. (I use Dart, not Javascript, so the code below is Dart; hopefully the answer makes sense.)
The idea is to have a new type of action in called ActionCreator<A extends Action> (subtype of Action). An ActionCreator<A> is an object with a method of type
A create(AppState state)
In other words, it takes the whole AppState and returns an Action. This lets it do the necessary data lookups. As an object, it can contain fields that describe data gathered from the code (usually View event handler code) that instantiated it. For example, it could reference a Selectable to select. create() returns either null or some special value to indicate that the action should be thrown away.
For example, if we have a click handler, we'd dispatch an ActionCreator
class Select {
final Item item_clicked;
Select(this.item_clicked);
}
class ClickedAction implements ActionCreator<Select> {
final Item item_clicked;
ClickedAction(this.item_clicked);
Select create(AppState state) =>
state.ui_state.select_mode_is_on ? Select(this.item_clicked) : null;
}
// ...
onClick = (event) {
props.dispatch(ClickedAction(props.item));
}
And in middleware, once we have access to the full state, this can be turned into a concrete action, but only if it's legal. But the nice thing is that the next piece of code is generic and handles any such ActionCreator, so I wouldn't have to remember to keep editing this code whenever I create a new Action that needs to be "conditionally dispatched".
action_creator_middleware(Store<AppState> store, action, NextDispatcher next) {
if (action is ActionCreator) {
var maybe_action = action.create(store.state);
if (maybe_action != null) {
dispatch(maybe_action);
}
} else {
next(action);
}
}
The disadvantage of this is that it's still dispatching many more actions than we really need; most will get thrown away. It's a "cleaner" implementation of what I need, but I still think that for asynchronous event handlers, access the Redux store as a global variable is probably perfectly fine. I don't see in that any of the problems one would expect if the view code went outside of its React props and accessed global variables.
I have a sap.m.TabContainer control with multiple sap.m.TabContainerItem controls. Each of the TabContainerItem controls have a number of their own controls on them. I have created a custom control (DBPanel) with a label and text field. It also has an enabled property for which I have overridden the setEnabled(boolean) method to enable/disable the internal text field within DBPanel. There are five (5) of these DBPanel controls on a specific TabContainerItem. When I call setEnabled(true) on each of these DBPanels, only three of the five become enabled. When I switch to another TabContainerItem and then back to this one, the final two DBPanels are also enabled. It is almost as if the TabContainerItem needs to be re-rendered. But I have read elsewhere that if rerender or invalidate need to be specifically called then there is something wrong with the code.
Any help would be appreciated.
Thank you
At your overridden method, you can try to call the original method that is extended. If you don't need extra logic rather than disabling or enabling it, you don't need to extend that method but I guess you have some.
First check whether superclass implements the method and then call the
method with the original arguments
if (DBPanel.prototype.setEnabled)
DBPanel.prototype.setEnabled.apply(this, arguments);
I am trying to attach change event handler to the instance of kendoNumercTextBox.
I am able to get the instance of kendoNumercTextBox control using its ID, however Im not able to get the instance using class name
here is the code http://dojo.telerik.com/emIWa/11
NOTE
I DO NOT want to attach event handler at the time of instantiating
the control. I want to get the existing instance and then attach the
event handler.
Also i am actually using Kendo ASP.NET MVC, however
dojo doesn't allow me to write cshtml so i am using kendo UI for
the demo purpose above. But i think end result would be same.
The NumericTextBox is created like below in cshtml
#(Html.Kendo().NumericTextBoxFor(x =>x.numerictextbox).HtmlAttributes(new {#class = "MyClass"}))
You need to use a more specific jQuery selector. This for example will get the correct element which is the one with the data-role attribute:
var numerictextboxByClassName = $(".MyClass [data-role]")
If you use the developer tools in your browser to inspect the text box, you'll see that 'MyClass' is on several elements that comprise the widget, hence the need to be more specific. It is also worth noting that the handler will only attach to the first instance found using the selector so this method cannot be used to attach a handler to several such controls at the same time.
I want to get the list of all events for any particular component dynamically. For example : If I take a Textfield , how can I get all possible events that are mentioned in ExtJs API Doc. so that user can choose and assign the event for any component.
component.events
Contains the list you need. You could have found out by yourself reading the source of addEvents method, which is linked from any event you wanted to find in a list.
For those still wanting an answer to this, https://coderwall.com/p/jnqupq/easily-capture-all-events-on-a-component-in-extjs has provided a nice means of doing so.
When debugging an ExtJS application, you'll often find it useful to listen to all events fired by a specific component. There is actually a handy built-in static method to do this called Ext.util.Observable.capture().
Here's a handy snippet that simply logs the event name and all arguments:
Ext.util.Observable.capture(myObj, function(evname) {console.log(evname, arguments);})
Even better, if you're currently inspecting your component's main element in your browser's developer tools, you can do this:
Ext.util.Observable.capture(Ext.getCmp($0.id), function(evname) {console.log(evname, arguments);})
Where $0 is the currently selected element. Should work fine in Chrome, Firefox, Opera, Safari.
If you don't want those logs to pollute your console anymore, simply call releaseCapture on your object:
Ext.util.Observable.releaseCapture(myObj);
This removes all captures on a given object so you don't have to reference your listener explicitly (which was likely an anonymous function :)).
Bonus tip: also be sure to check out the observe method which does something similar but allows you to listen to all events fired by all instances of a given class.
In the course of the development of a Resharper plugin, I'd like to show an error message to a user when they incorrectly use a context action. Is there a way to pop up a window in Visual Studio to communicate the Resharper exception message to the user? I'm developing a plugin with Resharper 8 and VS 2012
You can always use MessageBox - ReSharper also provides a MessageBox static class that provides a number of helper methods to make it easy to display what you want. It also allows for adding "message box handlers" so that you don't actually display a message box during testing.
Alternatively, if you're creating a context action, and you're (indirectly) deriving from BulbActionBase, your ExecutePsiTransaction method (which should do all the work) can return an Action<ITextControl>. This allows you to return an action that will execute after the quick fix/context action has completed, which can be anything from positioning the caret, changing the selection, executing a template or showing a tooltip as an error.
You can return something like this:
return tc => myLocks.QueueReadLock("MyContextAction", () => {
myTooltipManager.Show("Something went wrong!",
lifetime => new TextControlPopupWindowContext(lifetime, tc, myLocks, myActionManager);
});
This is using a number of fields: IShellLocks myLocks, ITooltipManager myTooltipManager and IActionManager myActionManager. These can be injected into a component's constructor by ReSharper's component model, or you can get them with solution.GetComponent<IShellLocks>, etc.
What's happening is that you're returning an action that takes in an ITextControl, and which immediately queues up another action to run, on the UI thread, with the read lock taken. This second action tells the tooltip manager to show an error message as a tooltip, and provides a factory method for creating a popup window context (the lifetime parameter is created and disposed by the call to Show, and allows for cleanup of the context).
You could also look at the ShowAtCaret extension method to ITooltipManager - I can't remember offhand where Show will place the tooltip.