I am developing a multitouch application, and I will use TUIO-Based approach. When the JavaFX application receives TUIO event, it should translate it into TouchEvent and fire them.
However, the TouchEvent.impl_touchEvent function, which can generate TouchEvents, is deprecated. Also the touchEvent constructor is private, so we cannot create TouchEvent by our own. Is there another way to generate TouchEvent in JavaFX 2.2?
In Java 8 event creation in user code is supported by: RT-9383 Add proper constructors & factory methods to event classes, remove impl
An early access version of Java 8 with this functionality is available for download.
You can look at my answer on events generating here : How to send events from one Node to another Node
Seems, for touch event - you will need to replace on of parameters there.
As a hint - you can download openJFX sources, and look on implementation of according classes.
Related
We are working on plugin for ReSharper and we want to make our plugin extensible. Seems, we should use ShellComponent attribute to do it but we can not find any examples. Could anybody enplane how to define custom extension point and how to manage extension. Example of code of extension point and extension implementation would be very helpful.
Thanks.
If you're looking to write a plugin that can extend ReSharper, you need to tell ReSharper about the classes in your plugin, by marking them with the [ShellComponent] or [SoutionComponent] attributes. These attributes have different lifetimes - a shell component lasts the lifetime of ReSharper itself, and a solution component is created when a solution is opened and disposed when the solution is closed.
To make ReSharper do something useful with your components, they typically have to implement an interface, such as ICodeCompletionItemsProvider, and sometimes have to use a different attribute, such as [CodeCleanupModule] (which itself derives from ShellComponentAttribute). There are many extension points in ReSharper, and the one that's appropriate for you depends on what you're trying to do - refactoring, unit test provider, code cleanup, code completion items, etc. The devguide provides a good introduction to the more common extension points.
But if you want to make your own plugin extensible, then your component needs to work with a kind of provider pattern, by deferring work to multiple provider instances. For example, code cleanup works by deferring to multiple code cleanup modules, each responsible for cleaning up a different aspect of your code (whitespace, ordering, etc). To do this, your component should take in a collection of providers in the constructor. ReSharper's component model will automatically create a collection of these types and pass them to. More specifically, you should have a constructor that takes an IEnumerable<T> or IViewable<T>, where T is the interface of the provider you're going to define and call. The IEnumerable<T> will give you a simple collection of providers, but IViewable<T> represents an observable collection, and allows you to subscribe to notifications of new providers being made available from the component model.
I am currently using Asp.Net MVC 4 and I would like to include the time of some routines used by my controllers in the glimpse's timeline tab.
I know that I have to create an ITimeLineMessage Implementation and send the timing information with a message broker. But how to create the ITimeLineMessage ?
Here is an implementation using anthonyv's suggestion:
https://gist.github.com/droyad/8292852
Here is a way but its not very nice and not supported:
Retrieve the MessageBroker for the following static method:
Glimpse.Core.Framework.GlimpseConfiguration.GetConfiguredMessageBroker()
Then publish an ITimelineMessage to the MessageBroker:
messageBroker.Publish(timelineMessage)
Note, you could create a generic message type that you use over again that implements ITimelineMessage
To populate the properties of your ITimelineMessage implementation you might also need IExecutionTimer. You can get this via the following static method:
Glimpse.Core.Framework.GlimpseConfiguration.GetConfiguredTimerStrategy()
The above will have the knowledge of when the request started for offsets etc.
As #nikmd23 said, we know this is about as bad as what you could ever want to do but v2 will see a much much more simple way of doing this.
You can create any custom class you want, that class just has to implement ITimelineMessage.
As a general heads up, we are currently working through a way to make this WAY easier. If the approach described there interests you, please do provide your feedback.
The generated designer.cs properties are private by default (at least without manual tweaking of generated code). This makes coding against something like a UITableViewCell feel much different than if I were doing this in Objective-C.
The popular way in the case of UIxxxViewCells, at least from what I can tell, is for the UIxxxViewDataSource to populate the IBOutlet properties, and that the cell should only be responsible for anything related to drawing/rendering the view.
With Xamarin.iOS, we are unable to access these properties from the data source, and instead are required to provide additional setter methods to populate the cell. In this way, the cell is responsible for setting it's own properties.
Is this just "The .NET way" of doing things?
It's so that we don't break encapsulation by default.
The outlets belong to the object they're on, it should be able to choose whether they're able to be modified from the outside. The fact that they're properties is an implementation detail of the Xamarin.iOS outlets system - you should think of them as private fields.
If you wish to expose them, you can create properties that do so - preferably read-only.
It was probably done that way because that's how the other GUI designers in MonoDevelop worked at the time (still do). Auto-generated bindings to the native controls used by the user-designed control for toolkits like Gtk# are also created as private.
I'm not sure if other UI designers for .NET work (I've never used Visual Studio to develop GUI apps using Windows.Forms or WPF).
Feel free to file a feature request on https://bugzilla.xamarin.com to make them public - I'll gladly implement it, I think it probably makes more sense for them to be public. I haven't changed it mostly because no one has expressed that they wanted it be any other way.
What is equivalent to com.ibm.xsp.model.domino.wrapped.DominoDocument in org.openntf.domino API? I'm using this class when I send NotesXSPDocument to my java class from SSJS.
There is no replacement for this class in the OpenNTF Domino API, which is designed to enclose and enhance the lotus.domino classes, not any of the com.ibm.xsp classes.
However, if you the org.openntf.domino.xsp plugin that comes bundled with the project and put it in "godmode" for your server or NSF, then any DominoDocument wrapper that you encounter will have an org.openntf.domino.Document instead of it instead of just a lotus.domino.Document. That way your Java class will get the right class automatically.
Alternatively, you can always manually wrap your lotus.domino.Document by using Factory.fromLotus([Document], org.openntf.domino.Document.class, null) But I would generally recommend using the plugin. It's much simpler and keeps you from having to worry about the implementation of the openntf version.
I come from a very proficient Windows .NET background and I'm having a go with Monotouch and I am very confused as to how to respond to events. I like to keep things simple and I have read the Montouch tutorials and looked at the examples. What I'm getting confused about is how to respond to events.
Lets say I have ViewController with a UIButton and a UILabel on it. When I press the button I want to change the label to say "Clicked button".
Therefore I could just do the following:
public override void ViewDidLoad () {
base.ViewDidLoad ();
this.btnClickMe.TouchUpInside += (sender, e) => {
this.lblOutput.Text = "Clicked # " + DateTime.Now.ToShortTimeString ();
}
OR alternatively, I could use this approach which I think would serve me better when it comes to responding to buttons pressed in NavigationBars etc.. In IB I Ctrl-Drag to create an Action. I then move the [Action] method to my .cs file and do the following.
[Action ("btnClickMe_TouchUpInside:")]
public void btnClickMe_TouchUpInside (NSObject sender)
{
this.lblOutput.Text = "Clicked # " + DateTime.Now.ToShortTimeString ();
}
What makes it more confusing for me is some UI components have a .delegate member. To which I can an add an event.
Whats the best method or am I getting totally confused? If so is there is a link you can direct me to where I can learn the best practice, the right approach etc..
Many thanks
Mike
For a good introduction, I recommend Xamarin's article on Events, Protocols and Delegates.
As far as your question of wiring up Action Outlets versus hooking events to Referencing Outlets, they have this to say:
The main difference between using .NET events as opposed to
target-actions is that the latter allows you to wire up multiple
controls to a single action method.
So, you might be inclined to use the action approach if you were building a quick & dirty calculator, and pressing the numbers 0-9 all do the same thing-- you can just read the digit from the button. (If you ever used VB to create a control array, you might be familiar with this technique.)
That said, I find my personal preference is to stick with Reference Outlets. It requires less thinking and going back & forth between MonoDevelop and the Interface Builder. I drop in a UISlider & reference it, then I have access to all of its properties & events from the code. So, hooking something later can be done from the code. Many developers have commented that they trend away from using IB...
Getting back to the facts, MonoTouch offers multiple redundant ways to interact with the UI. For those coming from Objective-C, you will find the familiar "Objective-C Delegates" and references to "selectors". Coming from C#, you can often ignore those approaches. But, you should take the time to read that article so you'll be familiar with the language used in Apple documentation. For example, it is important to note the difference between "Objective-C Delegates" and "C# delegates".
Delegates are used for callbacks in iOS similarly to the way .NET uses
events. To make iOS APIs and the way they use Objective-C delegates
seem more like .NET, MonoTouch exposes .NET events in many places
where delegates are used in iOS.
In time, I believe you will find the API flexible and accommodating of .NET patterns. Converting between the NS types and .NET types is often transparent (e.g. from a lambda expression to an NSAction).
Let me know if you need more specific information.
Cheers.