|
ToBick wrote: if any .net control is available to compare pictures like it is done with the following Flash-Control:
Your example shows two pictures side by side. I do not see a "comparison".
ToBick wrote: If not - how would you realize this in C#?
I'd load two images in two panels.
Please explain a bit more what needs be compared (picture size, colors, what?), who should do the comparison (the computer, or the user? Your example implies that the user is going to compare them by looking at them) and what the result should be like.
Bastard Programmer from Hell 
if you can't read my code, try converting it here[^]
|
|
|
|
|
Hi,
what i'd like to do is shown also in the following link:
http://www.spiegel.de/panorama/vorher-nachher-grafik-so-verheerend-war-der-tsunami-a-750653.html[^]
Basically, i want to put two pictures above each other and have a "slider" which i can move with the mouse to the left or the right - the part left to the slider belongs to picture No. 1 and the part right to the slider belongs to picture No. 2
Thereby, i can compare a picture which shows the same object before and after a modification.
|
|
|
|
|
A SplitContainer[^] control. Drop two Panels onto it, and draw the appropriate part of the image manually.
--that would assume WinForms, not WPF or web; what UI are you targetting?
Bastard Programmer from Hell
if you can't read my code, try converting it here[^]
|
|
|
|
|
Winforms - so i'll try it like that. However i'm not sure if the width of the split-container slider is not a little bit too high - what do you think how the performance would be (size of both pictures is < 100kb) if i just use one picture box in which i draw the picture depending on the mouse position - i could also just create a line from bottom to top at where the mouse pointer is to seperate it + show an icon as a handle...
|
|
|
|
|
I think performance will largely depend on the bitmaps used, their dimensions and their depth. I think the performance would be quite well, it's not a very heavy task cpu-wise.
The width of the slider can be set using a property, and a PictureBox doesn't add much over a Panel. You'd still have to draw it yourself, and, after a mousemove, invalidate and repaint the affected part - not the entire bitmap.
Bastard Programmer from Hell
if you can't read my code, try converting it here[^]
|
|
|
|
|
Your biggest performance hit will come with the algorithm that you use to generate the "after" image. That's where most of the computation will occur.
|
|
|
|
|
There is no direct API available for this.
However, some articles like this[^] could come to your aid - do a search on the internet and you will find more blogs that could help you.
|
|
|
|
|
Hello there. I have a class which is designed to have only one instance. I instantiate this class in the main dialog. Then in one of my tabs, I try to get this class' object but it stated
Object reference not set to an Instance of an object
Here is what I am trying to far.
public class SingleClass
{
public SingleClass SingleObj {get;set;}
public MainDlg MainDlgObj {get;set;}
public SingleClass(ref MainDlg main)
{
SingleObj = this;
MainDlgObj = main;
}
}
public class MainDlg
{
SingleClass sc;
public MainDlg()
{
var MainDlgObj = this;
sc = new SingleClass(ref MainDlgObj);
}
public void ShowMessage()
{
MessageBox.Show("Hello From MainDlg");
}
}
Now in one of my tabs in this main dialog, I am trying to call this ShowMessage() method via SingleClass like this but it gives the said error
public class Tab1
{
SingleClass sc;
public void Function_InTab()
{
sc.SingleObj.MainDlgObj.ShowMessage();
}
}
The code compiles well but it fails at runtime with the said error. How can I show ShowMessage() here? Thanks for any input.
This world is going to explode due to international politics, SOON.
|
|
|
|
|
Without using static, your classes here must be instantiated. I must say though, that your hierarchy is a complete mess. You need to do a rewrite of this - you might possibly want to consider something like this:
public interface IMessage
{
void ShowMesage();
}
public class MainDialog : IMessage
{
public MainDialog() {}
public void ShowMessage()
{
MessageBox.Show("Hello");
}
}
public static class SingleObj
{
public static void ShowMessage<T>() where T : IMessage, new()
{
T dialog = new T();
dialog.ShowMessage();
}
}
public class Tab1
{
public void Function_InTab()
{
SingleObj.ShowMessage<MainDialog>();
}
}In this code sample, you can see the use of the static modifier to make ShowMessage single instance. More importantly, you can see that we have used generics with constraints to get a somewhat more pleasing design for the case where we simply want to show a message. You can extend and adapt this as to cater for more complex designs, but bear in mind that a single instance class can often be considered to be a code smell - make sure you use it wisely.
|
|
|
|
|
AmbiguousName wrote: I have a class which is designed to have only one instance.
Why not simply use a static class?
KISS.
Bastard Programmer from Hell
if you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: Why not simply use a static class?
I would love to but in my current environment, they are considered plague 
This world is going to explode due to international politics, SOON.
|
|
|
|
|
AmbiguousName wrote: I would love to but in my current environment, they are considered plague
..may I ask "why"?
Singletons are so common that the Framework provides a built-in version. I seriously like to hear any argument on not using them. Enlighten me, why do you take the long road when there's a well documented shortcut that has been specially built for that purpose?
Bastard Programmer from Hell
if you can't read my code, try converting it here[^]
|
|
|
|
|
Well I myself like static stuff very much. But the only answer I am provided is that: debugging becomes very tough. Two things are considered plague here.
1 - Static stuff
2 - extern
Experience speaks for itself. May they are right in their decisions. But at the moment I want to do this without static.
This world is going to explode due to international politics, SOON.
|
|
|
|
|
AmbiguousName wrote: But at the moment I want to do this without static.
I'll shut up then 
Bastard Programmer from Hell
if you can't read my code, try converting it here[^]
|
|
|
|
|
Static can be abused and lead to very bad programming practices which is probably why they are considered bad.
However, a corectly implemented Singleton[^] is a special use case that fits your situation perfectly so should be used IMO.
|
|
|
|
|
Thank you for the link. This was really informative for me.
This world is going to explode due to international politics, SOON.
|
|
|
|
|
Singletons are just static classes hidden behind a layer of obfuscation. They are worse
|
|
|
|
|
BobJanova wrote: Singletons are just static classes hidden behind a layer of obfuscation
Would you care to expand on this as I'm pretty sure that's incorrect?
|
|
|
|
|
Sure. Access to a true singleton is via a static method (the getter of an Instance property in C#, but it's still a method). By definition, you can only get one instance, so there's only one available area for state storage, and the type of that instance is known at instantiation time.
The only one of those things that is not directly repeatable by a static class is the last, if you have some sort of factory that returns an instance for a singleton based on something else. Even then, you can delegate the methods which have actually changed from static methods. And such a method would normally be indicative that you should be using dependency management instead of manually coded singletons, anyway.
Let's look at a simple example, in pseudo:
singleton class MyClass {
public static singleton Instance { create { return new MyClass() } };
private int nextID = 100;
public int NextValue() { return nextID++; }
}
This can be directly replaced with
static class MyClass {
private static int nextID = 100;
public static int NextValue() { return nextID++; }
}
... that is, by making all methods and state static, and removing the singleton code. This also means that you aren't wasting memory for an object instance that is there simply to wrap methods and application-wide (i.e. static) state.
|
|
|
|
|
Thanks for your reply.
There are a couple of other things that you can do with a singleton that you can't do with a static class...
A singleton, being a class instance, can be passed as a parameter, be inherited from, implement interfaces and probably many other things too.
I take your points (all valid) on board, but I still feel that there is a distinct, and often benificial, difference to a static class.
|
|
|
|
|
You are probably right, I overstated that one slightly. However, if you're passing an object around, most of your code isn't interested in it being a singleton, and you should perhaps wonder if it needs to be one at all.
|
|
|
|
|
The problem here is that the sc instance in Tab1 is a local variable, which in fact is never set so it's null. You need to refer to the single instance you created before.
Actually it seems like what you want is a singleton of MainDlg. SingleClass is a complete waste of space as it's just delegating to MainDlg. So how about
class Singleton<T> where T: new() {
private static object lockObject = new object();
private static T instance;
public static T Instance {
get {
if(instance == null){
lock(lockObject) {
if(instance == null) instance = new T();
}
}
return instance;
}
}
(I think that's the standard singleton pattern as current best practice in C#?)
And then when you want access to the main dialog for UI purposes you can do
public class Tab1
{
public void Function_InTab()
{
Singleton<MainDlg>.Instance.ShowMessage();
}
}
Edit: added .Instance into the last function, and static to the singleton code (duh).
modified 18-Jul-12 8:26am.
|
|
|
|
|
I'm afraid that your Singleton<T> implementation will not guarantee that only a single instance will exist. There is nothing to prevent calling new on the T class. In fact invoking your Singleton implementation twice will create a new instance each time!
Here's how I deal with singleton's:
public sealed class Foo
{
#region Singleton
private static readonly Lazy<Foo> _Instance = new Lazy<Foo>(() => new Foo());
public static Foo Instance { get { return _Instance.Value; } }
private Foo()
{
}
#endregion
public void Method()
{
}
}
Usage like:
Foo.Instance.Method();
It is NOT possible to create a singleton without the Instance property and the _Instance backing field being static. Something has to exist outside the specific instance of the class.
There are lots of articles about the singleton pattern, I suggest you read a few.
|
|
|
|
|
It will guarantee it if the person writing the code respects the interface – which considering he has access to the source of Foo is all you can rely on anyway.
Putting the singleton code inside the class means that it is duplicated in every class that you want Singleton behaviour for. I prefer to rely on an intelligent developer and avoid code duplication. This is a similar approach to that taken by dependency injection frameworks, where you still can manually create objects, but you are trusted not to do so if it's inappropriate.
In fact invoking your Singleton implementation twice will create a new instance each time!
Now that I believe not to be the case, since Singleton<T>.Instance checks for the existence of an instance (in fact that is the entire purpose of the Singleton class).
Edit: though I had forgotten to declare the instance field and property static 
modified 18-Jul-12 8:27am.
|
|
|
|
|
Your edit corrected the basis for my comment that the Singleton did NOT guarantee only one instance!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
