|
As you have bought AmiBroker, I would expect their online support[^] to be the best source for information like this.
This space for rent
|
|
|
|
|
No, it is a trial version.
|
|
|
|
|
So you're going to buy it then? Or are you looking for help to crack the application?
This space for rent
|
|
|
|
|
Trial or no, it is not part of the Framework. Any decent sales-team would happilly provide you with access to their support team 
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Hi all,
i have a MyPanel type custom control,
MyPanel panel1;
i pass this to another temp variable
MyPanel temp=panel1;
now i remove some control from temp,
but here the remove control also remove from panel1.
please help how can i stop this.
thanks in advance.
|
|
|
|
|
What you're seeing here is the behaviour you'd expect because you are passing a reference of panel1. In other words, you are passing the object itself and not a copy of the object. If you want the behaviour to be different, you're going to have to pass a copy or clone of panel1 to the other location.
This space for rent
|
|
|
|
|
Le@rner wrote: the remove control also remove from panel1.
Of course it does, they are one and the same object. If you want a different object in temp then you need to make a copy.
|
|
|
|
|
It's a little hard to get your head round, but it's pretty simple when you do.
So let's ignore it for a moment, and talk about cars.
Suppose you get in your car and put your mobile in the glovebox.
If you later get in my car and open the glove box, will your mobile be there?
No - it's in your car, not mine: they are separate instances of the generic class "Car", and you do not expect items to magically move between them!
But...suppose my wife an I both share a car. If she puts her mobile in the glove box of "her car" and I later look in the glove box of "my car" what will I see? Her mobile of course! Why? Because "her car" and "my car" are different references to the same actual vehicle - the same instance of the generic class "Car".
In computer terms, the two scenarios are like this:
Car yourCar = new Car("Blue");
Car myCar = new Car("Red");
yourCar.GloveBox.Add(yourMobile);
if (myCar.GloveBox.Contains(yourMobile))
throw new UniverseException("How did that happen?");
And
Car myCar = new Car("Red");
Car herCar = myCar;
herCar.GloveBox.Add(herMobile);
if (myCar.GloveBox.Contains(herMobile))
Console.WriteLine("Found it dear! You left it in the glovebox again!");
You are doing the same thing with your class:
MyPanel panel1 = new MyPanel();
MyPanel temp = panel1;
temp.Controls.Remove(button1); This is because classes are what is called a Reference Type: a variable of the class doesn't contain the actual class, but a reference to it in the same way that "my car" doesn't contain the actual car, but refers to a specific vehicle.
Integers and so forth are Value Types: they do contain the actual value so when you say
int i = 666;
int j = i;
j = j / 2;
Console.WriteLine("{0}:{1}", i, j);you will get "666:333" - and any other result would make maths very difficult to do!
If you embed the integer in a class:
public class MyClass
{
public int i;
}
...
MyClass m1 = new MyClass;
m1.i = 666;
MyClass m2 = m1;
m2.i = m2.i / 2;
Console.WriteLine("{0}:{1}", m1.i, m2.i);you will get "333:333" because the references m1 and m2 are "talking about" the same instance of MyClass.
Some of this may make it easier to understand: Using struct and class - what's that all about?[^] - but it gets a bit advanced from the section "It's never that easy, is it?" so you might want to stop there for the moment!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
You won't "stop this:" what you observe is the way that object references are supposed to work;
multiple variables can hold copies of the pointer to the instance of a Class or Struct.
To create another instance of 'MyPanel which is "independent" of the first instance you have to ... well ... create another instance or "clone" the first instance; by clone, I mean create a new instance and copy the values of all Fields, Controls, Properties, etc. No, there's no built-in operator to do this.
What you probably want to do is to create a UserControl (they are about as light-weight as a Panel); first create a UserControl with the minimum number of Controls ... the "simplest" version ... then create another UserControl and modify it's Class definition so it inherits from your first UserControl:
1. the first Usercontrol's constructor:
public partial class MyCustomPanel : UserControl
{
public MyCustomPanelSimple()
{
InitializeComponent();
}
}2. the second UserControl's modified constructor:
public partial class MyCustomPanel2 : MyCustomPanel
{
public MyCustomPanel2()
{
InitializeComponent();
}
}Assuming you've put one Button on the first (simpler) UserControl, you'll find that when you open the design-view for the second UserControl that Button appears, and is 'locked; you can't assign EventHandlers to its Events. But, the Button is ... there. You just have to do this to get access to it:
public MyCustomPanel2()
{
InitializeComponent();
TheButton = Controls["customPanelButton1"] as Button;
}
private Button TheButton;Or, you can do an evil thing, and go make the access modifier for the Button in the first Panel (simpler) 'public: to do that you have to modify the declaration of that Button in the designer.cs file which is a very wicked thing to do ... better you should get a reference in the (lame) way shown here. In case you wonder why Microsoft made creating Form/Control inheritance so painfully awkward to implement, be assured you are not alone.
One way to avoid this awkwardness is to make your custom Controls "composite:" make the simplest one, then make another one where you drag-drop an instance of the first one onto the design surface of the second one where you add additional Controls ... and, so on. And, then you can have fun getting references to the interior Controls of your UserControls-in-UserControls.
«There is a spectrum, from "clearly desirable behaviour," to "possibly dodgy behavior that still makes some sense," to "clearly undesirable behavior." We try to make the latter into warnings or, better, errors. But stuff that is in the middle category you don’t want to restrict unless there is a clear way to work around it.» Eric Lippert, May 14, 2008
|
|
|
|
|
|
Hi,
I call a class which in turn inherits an API class. That class calls another class which returns a value.
Class1 calls Class2.
Class2 inherits Class3.
Class3 calls Class4 that returns a value. The input to return the value is null. However, Class3 and Class4 are wrapped in an API. So you cant edit it.So it throws an error in Class1. How do I ignore this error?
Thanks
|
|
|
|
|
You shouldn't really ignore errors - you should find out why they occur! It's normally something important you've done wrong...
About all you can do in this case os use a try...catch block in class1 and / or class2 to catch the error, log the problem somewhere and continue from there. You can't tell the class3 or class4 to "ignore that and carry on" because the error is saying "I don't know what to do, I can't carry on". That's why it's important to find out why the error occurs - what is null, and why is it null? Fixing that is the only way to prevent the classes throwing the error in the first place!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
This is the error.
An unhandled exception of type 'System.ComponentModel.LicenseException' occurred in System.dll
|
|
|
|
|
Sounds like you need a license to use the API, and it's not being recognised.
We can't fix that for you - you need to speak to the authors of the API and get them to help.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Hi,
I have an Interface. I call the interface from my form as this.
IExample myExample = null;
myExample.Height = 12;
But I get error that myExample is null.
Could I know what is the solution please?
Thanks
|
|
|
|
|
What did you expect?
You set myExample to null and immediately tried to reference the Height property of that.
The NullReferenceException is the only possible thing that can happen with this code!
Tell us what you are trying to do and then we can help you in the right direction.
"Fairy tales do not tell children the dragons exist. Children already know that dragons exist. Fairy tales tell children the dragons can be killed."
- G.K. Chesterton
|
|
|
|
|
When you declare an instance of the Interface and set it to 'Null, there's nothing "inside" the Interface. I think it would be better in this case if the compiler would refuse to compile that statement.
So, when you try and set the (assume it's the) 'Height property of the Interface instance, it's like you are saying, in effect: "let the Height of nothing be ..."
You need to first create an instance of a Class that inherits from the Interface:
public interface IDimensions
{
int Height { set; get; }
}
public class Dimensions : IDimensions
{
public int Height { set; get; }
public Dimensions(int height)
{
Height = height;
}
}
public Dimensions MyDimensions = new Dimensions(3);
MyDimensions.Height = 12;If this doesn't clear things up a bit for you, let me know.
«There is a spectrum, from "clearly desirable behaviour," to "possibly dodgy behavior that still makes some sense," to "clearly undesirable behavior." We try to make the latter into warnings or, better, errors. But stuff that is in the middle category you don’t want to restrict unless there is a clear way to work around it.» Eric Lippert, May 14, 2008
|
|
|
|
|
Thanks Bill. That was really helpful. But I have another interface again in the class that inherits one interface. I have again created another class that inherits the second interface. But where do I call that class in the first class? For example,
public interface ISettings
{
string Color { get; set; }
}
public interface IDimensions
{
int Height { set; get; }
ISettings Settings { get; set; }
}
public class Dimensions : IDimensions
{
public int Height { set; get; }
public Dimensions(int height)
{
Height = height;
}
}
Thanks
|
|
|
|
|
I have got it working like this.
public interface ISettings
{
string Color { get; set; }
}
public interface IDimensions
{
Settings objSettings = new Settings();
int Height { set; get; }
ISettings Settings
{
get
{
return objSettings;
}
set{ }
}
public class Settings : ISettings
{
string Color { get; set; }
}
public class Dimensions : IDimensions
{
public int Height { set; get; }
public Dimensions(int height)
{
Height = height;
}
}
Is this the right coding? It anyway worked for me.
Thanks
|
|
|
|
|
That code can't be right. An interface has no logic in it, and your IDimensions interface is implementing things. An interface is a contract - it tells you what the behaviour should look like, but not how it's performed.
This space for rent
|
|
|
|
|
As Pete commented, the code you show here won't compile.
A helpful metaphor could be: an Interface is like the blue-print for a house; the house is not a blue-print; and, the blue-print is not a house ... it makes no sense to try and combine a blue-print with a house. Yet, we can say there is a relationship between a blue-print and the house whose construction implemented the design specified in that blue-print.
But, to really describe what is happening in C#, we need to add one more ingredient to the metaphor, the Class (or Struct) as "factory:" the Interface is a blue-print for the Class, and the Class becomes a "factory" when you use it to create new instances of the Class. The house embodies, in a way, the blue-print, but it is neither blue-print, nor the workshop and construction tools used to build it.
Interfaces are useful for many things:
1. they are a contract which Classes or Structs that inherit from the Interface must "fulfill," or implement.
1.a. they assist you in organizing your code
2. they contribute to encapsulation and separation of concerns by allowing you to "hide" certain views of object instances of the Interface by casting them to the Interface. When cast to the Interface, the only "visible" parts of the instances are those which are specified in the Interface and implemented in the Class.
That allows you to pass the Class instance object to other Classes for processing with the guarantee that you cannot change/mess-with the other (now "hidden") Fields, Properties, Methods, etc., of the Class.
So, Interfaces are a way to control what a Class exposes.
3. Interfaces, combined with generic arguments allow you to create 'Factory objects which can produce instances of Classes with varying Types (this is an advanced topic).
Keep in mind that your design of Classes, Structs, Interfaces, Enums, etc. are all ways of expressing your intent. Hopefully, you intent directly expresses your goal: how you want your program to function; how you want your user-interface to handle asynchronous events, etc.
Here's a "guess" on what I think you may be intending:
public interface ISettings
{
string Color { get; set; }
}
public interface IDimensions
{
int Height { set; get; }
}
public class Settings : ISettings
{
string Color { get; set; }
}At this point you have several choices; you could have your 'Dimensions Class inherit from both ISettings and IDimensions:
public class Dimensions : ISettings, IDimensions
Or, you could have it inherit from the 'Settings Class and IDimensions:
public class Dimensions : Settings, IDimensions
In the first case, 'Dimensions would now have to implement a 'Color Property as well as a 'Height Property; in the second case, 'Dimensions would automatically use the 'Height Property defined in the 'Settings Class.
Using the first example: you would then have two options to Cast an instance of the Dimension Class to an Interface "view," or "type:"
// assume you have a 'ctor that takes two parameters
Dimension myDimension = new Dimension(100, Color.AliceBlue);
ISettings myDimensionAsISettings = myDimension as ISettings;
IDimension myDimensionAsIDimension = myDimension as IDimension;
You now effectively have two "restricted views" of the Class instance 'myDimension; you can pass the 'ISettings view to some other Class to use, perhaps modify, and be assured that whatever happens cannot affect the value of the 'Height Property.
Think about your intent, your goal, and keep experimenting and studying; in my experience (as a teacher), it does take time and repeated multiple passes over what 'Interfaces are, and how they work, for it to "sink in" 
«There is a spectrum, from "clearly desirable behaviour," to "possibly dodgy behavior that still makes some sense," to "clearly undesirable behavior." We try to make the latter into warnings or, better, errors. But stuff that is in the middle category you don’t want to restrict unless there is a clear way to work around it.» Eric Lippert, May 14, 2008
|
|
|
|
|
Hai All. i am a newcomer of c# forum. i have problem with password policy implemetation in c# . i checking password character. but i have doubt in password changing days every 90 days clause in password policy . how to check whether password change required or not ?
|
|
|
|
|
it depends on how and where the passwords are stored .. if you're using a database, one of the fields you might have in the account/user record is a datetime field for 'password last changed', and another might be a flag for 'needs to change password'
a) at day=0, you force a refresh of all passwords by setting the 'needs to change password flag' to true, and probably just put junk in the password field to force them to use the accepted password change procedure
b) when the user changes their password, you set the 'password last changed' field to (now), and the 'needs to change password' flag to false
c) every day, you run a procedure to go through the 'database' and calculate the difference in days between (now) and the password last changed field - if that figure is '90' you set the 'needs to change password' flag to true
|
|
|
|
|
As an addition to Garths design, I would have a settings table that stores the policy details. Instead of storing the needs to change flag and requiring a daily process to update it I would use a View which joins the settings table and the user table and calcs the need to change flag.
This eliminates a daily process and makes the policy and therefore the flag dynamic (controlled by the settings table and therefore available to be changed externally).
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Garth's way is fine, but rather than running a procedure every day, I'd do the "does it need changing" test when the user logged in. If it needs changing, then let him in, but take him directly to the "must change password" page, and don't let him in the rest of the site until it's changed.
I'd also dump the boolean "needs changing" value in favour of replacing the "last change" date with a "next change date". That way, then test is simple "is next change less than now?" and it's only one column to update when they do change it: nextChangeDueOn = CurrentDate + 90 days.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
