Lets say I have drawn a cube or a cylinder with Java3d. I would like to for example when I click on the surface of these shapes to build a small cone over it. I would appreciate if there is some examples.
thanks
Well i dont have a specific code for you but you could add a action listener to the cube. then with a serperate class with the code for a cone. This is not the entirety of the code but it should provide a good example.
public void class random1 {
cube.addactionListener(this);
}
public void actionlistener(ActionEvent ev)
if(ev.actionEvent = cube){
Random2 rad = new Random2();
rad.cone();
}
}
public void class Random2 {
public void cone(){
// code for the cone has to be in here
}
}
Related
I have a custom hover inside CDT editor (see the linked SO question) and now I want to show link inside my IAnnotationHover hover:
public class MyAwesomeHover implements IAnnotationHover {
#Override
public String getHoverInfo(ISourceViewer sw, int ln) {
return "<a href='www.stackoverflow.com'>so</a>"
}
}
Unfortunately the link is not shown - the hover window shows only simple text (i.e "so"). Other HTML elements I tried work OK (ul, li, p, font ...). Can anyone help me please?
As was mentioned in the comments, the RevisionHover was a good starting point. The magic is in implementing the IAnnotationHoverExtension and creation of a custom AbstractReusableInformationControlCreator. I am posting a code snippet with solution that worked for me.
public class MyHover implements IAnnotationHover, IAnnotationHoverExtension {
...
#Override
public IInformationControlCreator getHoverControlCreator() {
return new MyCreator();
}
...
#Override
public Object getHoverInfo(ISourceViewer sv, ILineRange lr, int vnl) {
return "<a href='www.stackoverflow.com'>so</a>";
}
...
private final class MyCreator extends AbstractReusableInformationControlCreator {
protected IInformationControl doCreateInformationControl(Shell parent) {
BrowserInformationControl control =
new BrowserInformationControl(
parent,
JFaceResources.DIALOG_FONT,
false);
control.addLocationListener(
new LocationAdapter() {
#Override
public void changing(LocationEvent ev) {
if (ev.location.startsWith("file:")) {
// !This opens the link!
openUrl(ev.location)
}
}
});
return control;
}
}
}
I am working on widows phone 8.1 map based application.I want to know how can I draw a map polyline using MVVM pattern. I've already achieved this using the code behind for first creating the polyline and then adding it. My question is can I define a polyline in the XAML itself and give it a source binding to one of my observable collections of type BasicGeopositions in my viewmodel. If yes then how?
Data to be plotted using polyline:
is a list of BasicGeoposition that contains latitudes and longitudes of all the points I need to connect. I tried this way <Maps:MapPolyline Path="{Binding Trip.PTSPositions}"/> but it didn't work. PTSPositions is a list of BasicGeoposition.
What i want to perform:
I want to
MapPolyline polyLine = new MapPolyline() { StrokeColor = Colors.Blue, StrokeThickness = 5 };
polyLine.Path = new Geopath(Trip.PTSPositions);
MyMap.MapElements.Add(polyLine);
perform the above code behind code in XAML using MVVM where the Trip.PTSPositions would be fetched dynamically and the map polyline would be drawn using data binding.
I searched online a lot. I couldn't find anything that does not use code behind for polyline
Here is the implementation suggested up in the comments.
This is the attached bindable property implementation for MapControl and it stays in the Widows Phone 8.1 project:
public class Polyline
{
public static readonly DependencyProperty PathProperty =
DependencyProperty.RegisterAttached(
"Path",
typeof(IBasicGeoposition[]),
typeof(Polyline),
new PropertyMetadata(null, OnPathChanged));
public static void SetPath(UIElement element, IBasicGeoposition[] value)
{
element.SetValue(PathProperty, value);
}
public static IBasicGeoposition[] GetPath(UIElement element)
{
return (IBasicGeoposition[]) element.GetValue(PathProperty);
}
private static void OnPathChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
{
var mapControl = d as MapControl;
if (mapControl == null)
{
throw new InvalidOperationException(
"Polyline.Track property can only be attached to a MapControl!");
}
mapControl.MapElements.Clear();
mapControl.MapElements.Add(CreateMapPolyline(GetPath(mapControl)));
}
private static MapPolyline CreateMapPolyline(IEnumerable<IBasicGeoposition> track)
{
return new MapPolyline
{
Path = new Geopath(track.Select(x =>
new BasicGeoposition
{
Altitude = x.Altitude,
Latitude = x.Latitude,
Longitude = x.Longitude,
})),
StrokeColor = Colors.Red,
StrokeThickness = 3,
StrokeDashed = false
};
}
}
This interface stays in the PCL, probably close to it's implementation (you'll have to add your custom class implementing the interface):
public interface IBasicGeoposition
{
double Altitude { get; set; }
double Latitude { get; set; }
double Longitude { get; set; }
}
Than in view model you have Trip.PTSPositions which is an array of IBasicGeoposition. And in the view (XAML), you'll have:
<maps:MapControl attached:Polyline.Path="{Binding Trip.PTSPositions}"/>
I have a class that only have main which read in some txt and do the algorithms.
my class is look like:
class doThejob{
public static void main(String args[]){
//*****start part A******
//do the reading from text file, and tokenize it
// process into the form I need,
//about 10-30 lines of codes
//******End of part A*****
//then run the algorithms
algorithm alg=new aglorithm();
Object output = alg.x(input);
//****Part B**** output to txt, about 10~40 lines
}
}
class algorithm{
private void a(Object x){
//do something
return (Object)result;
}
}
Can anyone tell me should I extract those part A and part B to a new class ,and then setup them as a public method .like below
class Io{
public Object readFromTxt(String path){
}
public void outputToTxt(String path){
}
}
And if I setup them , and then use it like below, is that more OOP?
class doThejob{
public static void main(String args[]){
Io dataProcess= new Io();
Object input = dataProcess.readFromTxt(args[0]);
algorithm alg=new aglorithm();
Object output =alg.x(input);
dataProcess.readFromTxt(args[1],output);
}
}
class algorithm{
private Object a(Object x){
//do something
}
}
Do it the way you fill is more readable.
Separating this in another class is according to the Single Responsability Principle. It will help making the code more readable and easy to change later on.
If you want to expand more on this, you could create an interface (eg.: IIO) for input and output. This way you can implement this interface in the IO class, renaming it to FileIO. Anytime you want to create another form of IO, like database access, you just have to create a DatabaseIO class that implements this interface and change the instance in the main method for this new type:
public interface IIO
{
string Read();
void Write(string text);
}
public class FileIO : IIO
{
string path;
public FileIO(string filePath)
{
path = filePath;
}
public string Read()
{
// read from file and return contents
}
public void Write(string text)
{
// write to file
}
}
public class SqlServerIO : IIO
{
SqlConnection conn;
public SqlServerIO(string connectionStringName)
{
// create the connection
}
public string Read()
{
// read from database
}
public void Write(string text)
{
// write to database
}
}
Extracting interfaces makes the code more maintenable by alowing to switch implementations anytime without messing with working code. It also facilitates unit testing.
Say I am writing a user interface for a hardware accessory. There are two versions of the accessory - let's say Widget Lite and Widget Pro.
Widget Pro can do everything that Widget Lite can do, but with a few more options and can do a few things that Widget Lite can't. In more detail, Widget Lite has one channel, widget Pro has two, so when it comes to something analogous to volume control, I need only one control for the Lite, but two for the Pro allowing independent control.
In my first attempt at building an application to handle this, I had the class representing Widget Pro extend Widget Lite, but then I've ended up with all sorts of conditional cases to handle the differences which seems ugly. Does anyone know a suitable design pattern to help with such a situation? My imagination is drawing a blank in coming up with synonymous situations that might help in my search.
I would start off by looking at the plug in pattern (one of the forms of Dependency Inversion).
Try and abstract an interface common to the Lite and Pro versions, e.g.
interface IBaseWidget
{
IControl CreateVolumeControl();
// ... etc
}
In separate assemblies / dlls, implement your Lite and Pro widgets:
class LiteWidget : IBaseWidget
{
int _countCreated = 0;
IControl CreateVolumeControl()
{
_countCreated++;
if (_countCreated > 1)
{
throw new PleaseBuyTheProVersionException();
}
}
}
Since you don't want to distribute the Pro version with the Lite deployment, you will need to load the dlls at run time, e.g. by Convention (e.g. Your base app Looks around for DLL's named *Widget.dll), or by Configuration, which finds the applicable concrete implementation of IBaseWidget. As per #Bartek's comment, you ideally don't want your base engine classfactory to 'know' about specific concrete classes of IBaseWidget.
Visitor pattern might be useful for you. Check dofactory.
Visitor class...
...declares a Visit operation for each class of ConcreteElement in the
object structure. The operation's name and signature identifies the
class that sends the Visit request to the visitor. That lets the
visitor determine the concrete class of the element being visited.
Then the visitor can access the elements directly through its
particular interface
This is similar to Abstract class implementation as told by Vikdor.
Here is a wiki link for this.
The visitor pattern requires a programming language that supports
single dispatch and method overloading.
I have provided a very simple implementation using the visitor pattern for your requirement of different channels and volume settings for WidgetLite and Pro. I have mentioned in comments where the visitor pattern will greatly help you in reducing the if-else calls.
The basic philosophy is that you pass the control (ex. volume) to the widget and it will know how to use it as required. Hence, control object itself has a very simplified implementations. Each widget's code remains together!!
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace WidgetVisitor
{
//This is the widget interface. It ensures that each widget type
//implements a visit functionality for each control. The visit function
//is overloaded here.
//The appropriate method is called by checking the parameter and this
//avoids the if-then logic elegantly
public interface Widget
{
void visit(Volume vol);
void visit(Channel chan);
void Display(AllControls ac);
}
//This is the interface which defines the controls. Each control that
//inherits this interface needs to define an "accept" method which
//calls the appropriate visit function of the right visitor,
//with the right control parameter passed through its call!
//This is how the double dispatch works.
//Double dispatch: A mechanism that dispatches a function call to different concrete
//functions depending on the runtime types of two objects involved in the call.
public interface WidgetControls
{
void accept(Widget visitor);
}
//I have implemented the volume control and channel control
//Notice how the code for defining each control is the SAME
//in visitor pattern! This is double dispatch in action
public class Volume : WidgetControls
{
public int volLevel { get; set; }
public int volJazz { get; set; }
public int volPop { get; set; }
public void accept(Widget wc)
{
wc.visit(this);
}
}
public class Channel : WidgetControls
{
public int channelsProvided { get; set; }
public int premiumChannels { get; set; }
public void accept(Widget wc)
{
wc.visit(this);
}
}
//Widget lite implementation. Notice the accept control implementation
//in lite and pro.
//Display function is an illustration on an entry point which calls the
//other visit functions. This can be replaced by any suitable function(s)
//of your choice
public class WidgetLite : Widget
{
public void visit(Volume vol)
{
Console.WriteLine("Widget Lite: volume level " + vol.volLevel);
}
public void visit(Channel cha)
{
Console.WriteLine("Widget Lite: Channels provided " + cha.channelsProvided);
}
public void Display(AllControls ac)
{
foreach (var control in ac.controls)
{
control.accept(this);
}
Console.ReadKey(true);
}
}
//Widget pro implementation
public class WidgetPro : Widget
{
public void visit(Volume vol)
{
Console.WriteLine("Widget Pro: rock volume " + vol.volLevel);
Console.WriteLine("Widget Pro: jazz volume " + vol.volJazz);
Console.WriteLine("Widget Pro: jazz volume " + vol.volPop);
}
public void visit(Channel cha)
{
Console.WriteLine("Widget Pro: Channels provided " + cha.channelsProvided);
Console.WriteLine("Widget Pro: Premium Channels provided " + cha.premiumChannels);
}
public void Display(AllControls ac)
{
foreach (var control in ac.controls)
{
control.accept(this);
}
Console.ReadKey(true);
}
}
//This is a public class that holds and defines all the
//controls you want to define or operate on for your widgets
public class AllControls
{
public WidgetControls [] controls { get; set; }
public AllControls(int volTot, int volJazz, int volPop, int channels, int chanPrem)
{
controls = new WidgetControls []
{
new Volume{volLevel = volTot, volJazz = volJazz, volPop = volPop},
new Channel{channelsProvided = channels, premiumChannels = chanPrem}
};
}
}
//finally, main function call
public class Program
{
static void Main(string[] args)
{
AllControls centralControl = new AllControls(3, 4, 2, 5, 10);
WidgetLite wl = new WidgetLite();
WidgetPro wp = new WidgetPro();
wl.Display(centralControl);
wp.Display(centralControl);
}
}
}
I would do it as follows:
AbstractWidget (Abstract class)
/\
/ \
/ \
/ \
/ \
WidgetLite WidgetPro
The common code would go into the AbstractWidget (abstract because, it shouldn't be instantiated) and the behaviour that is different between these two classes would go into the concrete classes.
I would strongly suggest that you have a base Widget class which both Widget Lite and Widget Pro derive from.
public class Widget {}
public class WidgetLite : Widget {}
public class WidgetPro : Widget {}
Have the properties/methods which are shared by both Pro and Lite inside the base class. This is a much cleaner design for you.
Could anybody please explain and give a real-live example of Composite Design Pattern?
The composite pattern can be used when a collection of objects should be treated the same way as one object of the same type. This is often used with tree-structured data. Below is an example where this pattern suits well:
public abstract class Shape {
public abstract void Draw();
}
public class Line : Shape {
public override void Draw() {
// Draw line
}
}
public class Polygon : Shape {
private IList<Line> lines;
public override void Draw() {
foreach (Shape line in lines) {
line.Draw();
}
}
}
As you can see, the pattern makes it possible for the code dealing with drawing shapes to be unaware of how many lines are drawn.