|
I think I understand now what you are meaning Dave.
It's when the program does run but gives you the wrong results is the other type of debugging.
Brian
|
|
|
|
|
Personally I would never call fixing compile time errors "debugging".
|
|
|
|
|
Look at your code.
public int Gold
{
get
{
return Gold;
}
...
}So now lets use it:
int g = myClassInstance.Gold; It enters the Gold getter, which returns the value of ... the Gold getter. Which returns the value of ... the Gold getter. Which returns the value of ... the Gold getter. ... until the stack blows and your app crashes.
The same happens when you try to use the setter: it infinitely recurses trying to set itself!
Create a private backing field:
private int _Gold = 0;
public int Gold
{
get
{
return _Gold;
}
set
{
if (value == 20)
{
value += 5;
_Gold = value;
}
}
}And it'll all work.
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Tbanks Griff.
It looks like I've created a continuous loop.
I'll try what you have suggested.
I noticed that you used _Gold instead of Gold.
Brian
|
|
|
|
|
_Gold is a member variable. Gold is the property that exposes the variable. Basically, if you attempt to get a property and return the property name instead of a variable, you're going to repeatedly call the same getter. This is what causes the StackOverflowException.
This space for rent
|
|
|
|
|
Hi Griff.
Your change worked when there was a test for the value of 20 but when I changed the test value to 30 then 0 was displayed on the form for the amount of gold, then when I clicked on the Test button the gold value changed to 35.
What I'm aiming at on this test is for 20 to first to appear on the form for the Gold value after the program is run, then when I press the Test button the gold value should change to 30 and in the test have 5 added to the 30 giving a gold value of 35.
Here is my code
On the main program I have
SuperAdventure.cs
<pre lang="c#"></pre>
public partial class SuperAdventure : Form
{
private Player _player;
public SuperAdventure()
{
InitializeComponent();
Location location = new Location(1, "Home", "This is your house.");
_player = new Player(10, 10, 20, 0, 1);
Update();
}
// TEST Button on Form
private void btnTest_Click(object sender, EventArgs e)
{
_player.Gold = 30;
Update();
}
public void Update()
{
lblHitPoints.Text = _player.CurrentHitPoints.ToString();
lblGold.Text = _player.Gold.ToString();
lblExperience.Text = _player.ExperiencePoints.ToString();
lblLevel.Text = _player.Level.ToString();
}
}
}
Player.cs code
namespace Engine
{
public class Player
{
// This is needed for _player = new Player(10, 10, 20, 0, 1,);
public int CurrentHitPoints { get; set; }
public int MaximumHitPoints { get; set; }
private int _Gold = 0;
public int Gold
{
get
{
return _Gold;
}
set
{
if (value == 30)
{
value += 5;
_Gold = value;
}
}
}
public int ExperiencePoints { get; set; }
public int Level { get; set; }
//In order to use lists – we need one variable or property to hold a collection of objects that are the same class
public List<InventoryItem> Inventory { get; set; }
public List<PlayerQuest> Quests { get; set; }
// This is needed for lblHitPoints.Text = _player.CurrentHitPoints.ToString() etc;
public Player(int currentHitPoints, int maximumHitPoints, int gold, int experiencePoints, int level)// : base(currentHitPoints, maximumHitPoints)
{
CurrentHitPoints = currentHitPoints;
MaximumHitPoints = maximumHitPoints;
Gold = gold;
ExperiencePoints = experiencePoints;
Level = level;
Inventory = new List<InventoryItem>();
Quests = new List<PlayerQuest>();
}
}
}
</pre>
|
|
|
|
|
The problem you have is that you don't assign anything to _Gold unless value is 30. This is because you do _Gold = value inside the if statement. Move this line outside the if block in your setter and it should start working.
This space for rent
|
|
|
|
|
Thanks Pete.
That was easier to fix than I thought it might be.
Brian
|
|
|
|
|
Not a continuous loop, but an "unbounded recursion" - similar thing, but the later will blow the stack at some point.
Just to add to what Pete says, the naming conventions say that a backing field should have the same name as the property it is associated with, but prefixed with underscore:
private int _MyProperty;
public int MyProperty
{
get { return _MyProperty; }
set { _MyProperty = value; }
}
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I twitch when I see a private backing field that has an uppercase letter following an initial underscore :  I'm sorry.
However, when I consider this example is still current in the MS docs [^]:
public enum Color {...}
public class Control {
public Color Color { get {...} set {...} }
}I throw up.
Remember the daze when common practice was to use: _mSomeName ?
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
|
|
|
|
|
Thanks everyone who has helped me with this code problem.
I now have a way of sending a value to a class, have the class change the value (if the test passes) and have the class return the result (which is displayed on the form.
Brian
|
|
|
|
|
Do keep in mind that MS Guidelines suggest using Properties only as gateways to internal fields [^] Quote: In general, methods represent actions and properties represent data. Properties are meant to be used like fields, meaning that properties should not be computationally complex or produce side effects. When it does not violate the following guidelines, consider using a property, rather than a method, because less experienced developers find properties easier to use.
not to produce 'side-effects" by way of internal computation in the setter and/or getter ... and advocates using methods to replace any internal computation.
While I feel "relaxed" about some computation in a Property setter/getter, there are folks who have strong opinions this is bad practice. Another argument against computation in Properties is that end-users of your code may not be aware of the "cost" of access.
Of course, you can implement INotifyPropertyChanged as a "trigger" for some external action.
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
modified 30-May-19 5:10am.
|
|
|
|
|
Hi Bill.
You wrote that
INotifyPropertyChanged can be used as a "trigger" for some external action.
Can you use this to auto add text to a rich text window on a form when you change the string variable in a class that the rich text window is connected to?
Brian
|
|
|
|
|
Brian_TheLion wrote: Can you use this to auto add text to a rich text window on a form when you ...
Theoretically, given the right structure, and valid references to run-time objects, the handler(s) that subscribe to the event can do anything any other method can do.
Take a look at the examples here: [^]
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
modified 30-May-19 11:01am.
|
|
|
|
|
@Brian_TheLion good article on INotifyPropertyChanged: [^]
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
|
|
|
|
|
Using Properties - C# Programming Guide | Microsoft Docs
The Master said, 'Am I indeed possessed of knowledge? I am not knowing. But if a mean person, who appears quite empty-like, ask anything of me, I set it forth from one end to the other, and exhaust it.'
― Confucian Analects
|
|
|
|
|
Gerry, I'm grateful for any knowledge I receive.
Brian
|
|
|
|
|
Hello,
I'm on WinForms and my window is FormBorderStyle.None. If the window is maximized and I drag the taskbar from the bottom to the side, the maximized window will not be adjusted to the new size. Events like LocationChanged, SizeChanged or Resize doesn't fire. What can I do?
Greetings
Ken
|
|
|
|
|
|
Hi Eddy,
this looks like a solution for WPF. But i'm on WinForms.
Greetings
|
|
|
|
|
It looks? So you stopped reading eh?
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Sorry, I know AppBar in WPF-Context. I took another look at it and compiled it. Looks promising.
|
|
|
|
|
First: the guidelines for Win apps warn against forcing the users to use some "fixed" style of UI: whether taskbar(s) auto-hide, and, where they are located, are usually left up to the user. Exceptions to this are "kiosk" apps, and single-purpose machines deliberately configured a certain way. Think long and hard before locking your user into a certain window configuration. Or, think about creating your own virtual desktop [^].
If you are showing a WinForm with 'WindowState = FormWindowState.Maximized, it will fill the screen completely, covering any TaskBars that are not hidden.
So, I do not understand your question ... yet.
Do you have experience with interop in C# using the Shell ... i.e., using WndProc, using P/Invokes ?
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
modified 28-May-19 23:36pm.
|
|
|
|
|
Hi Bill,
"
If you are showing a WinForm with 'WindowState = FormWindowState.Maximized, it will fill the screen completely, covering any TaskBars that are not hidden. "
I've solved this problem already with
private void frmMain_Load(object sender, EventArgs e)
{
MaximizedBounds = Screen.FromHandle(Handle).WorkingArea;
WindowState = FormWindowState.Maximized;
}
But: My application doesn't receive any event, that informs about the movement of the TaskBar. If i set FormBorderStyle.Sizeable everything is OK.
Do you have experience with interop in C# using the Shell ... i.e., using WndProc, using P/Invokes ?
Yes, i have.
Greetings
|
|
|
|
|
Ken Guru wrote: If i set FormBorderStyle.Sizeable everything is OK.
Please explain this further; it's "ok" because ? happens, or, because the user can ... ?
Does any issue arise if other apps have windows set to 'TopMost.
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
