|
|
I was debugging a Class that uses a Stack, and seeing puzzling results ... in terms of Stack contents ... when I realized a public read-only Property 'getter was using 'Pop: so, every time I inspected an instance of the Class in break-mode, the Stack was popped.
I was wondering if there is a compiler directive, or other means. to detect Class instance state being accessed in break mode, and block the 'Pop. My searches have not found an answer, yet.
thanks, Bill
«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
|
|
|
|
|
Popping an item off a stack is a run-time instruction; how could the compiler prevent that occurring? And that instruction should only execute in break mode if you step through it. I think we need more details.
|
|
|
|
|
thanks, Richard,
Keep in mind that I have set a break-point, and I am "opening" the current state of the Class instance to browse it by hovering over the source code using the IDE's inspector to view the current values of variables, and properties. So, there is a level of indirection in the code execution here.
My (weak) hypothesis that run-time break mode and instance drill-down detection in VS may be possible is based on the assumption that there's always something possible I don't know
cheers, Bill
«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 4-Jan-19 4:45am.
|
|
|
|
|
I have been debugging my (sometimes poorly designed) code with Visual Studio for years, and I have never had an occasion where inspecting a variable makes it change value.
|
|
|
|
|
Quite likely because you had the common sense to never pop a value off a stack ... and return the popped value ... in a property getter
Or, if you did that, and set a break-point and then inspected the class instance ... you weren't perturbed by the inspection calling the getter, and you were not crazy enough to imagine Visual Studio might provide a way during paused program execution to look around without side-effects.
«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
|
|
|
|
|
I cannot imagine how this is happening. Inspecting variables should not disturb them. The whole point of the debugger is that nothing changes unless you tell it to.
modified 4-Jan-19 12:38pm.
|
|
|
|
|
A getter property isn't a variable and doesn't have a value, it is a bunch of code that returns a value, so yes when asked for it will execute whatever code is present. That is good enough reason not to create side effects in a getter property.
|
|
|
|
|
Yes, of course it is, something I need to test.
|
|
|
|
|
Hi Bill,
a getter should not change object state, reading a property isn’t allowed to change anything.
That is why Random.Next is a method, not a property.
|
|
|
|
|
Thanks, Luc, Are you saying that a Property 'getter can't change anything, or are you expressing your opinion that a 'getter should not change anything ?
The issue here is the side-effect of browsing class instance values during a "break-state."
«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
|
|
|
|
|
a getter's role must be restricted to returning information about the object, it should not modify the state of an object, nor have any other side effects.
IMO a getter with side effects would breach OOP principles.
MSDN[^] states: "It is a bad programming style to change the state of the object by using the get accessor".
|
|
|
|
|
I always appreciate your opinions, Luc !
«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, Richard ! I have 'come around' to thinking that the Property should be replaced by a Method whose name makes it obvious what state will be changed. And, maybe I shouldn't be surprised at the side-effect of a 'getter whose value is inspected during a 'break state !
«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
|
|
|
|
|
You can know if a debugger is attached with
System.Diagnostics.Debugger.IsAttached
but you can't really know if the code is executed by the debugger. I think.
On another topic, such side effect of simply reading a property seems.. ill advised...
|
|
|
|
|
Thanks, LLoyd, that's a valuable thing to know about !
When you inspect a class instance in break-mode, you have, evidently, no way to prevent a specific public property 'getter from being called. Using 'IsAttached in code will work when you are running the release compiled .exe. In my experiments, running from within VS, using 'release mode, ;IsAttached is always 'true.
«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
|
|
|
|
|
we are working on POS System which is running based on server database but if internet is being disconnected then we need to use local system to store data entry and we r using SQL server database on server machine but we don't have sql server management studio is installed on local system. so how can we sync data from local system to server database ???
|
|
|
|
|
This is more of an architectural issue than a pure C# issue. Basically, you are going to need some form of synchronization framework (Microsoft supplied on called the SyncFramework a while back but this is largely an unsupported OS project now). The reason that this is an architectural issue is because you are going to need to put rules in place to decide how you want to handle the merge of data back. For instance, suppose you have sold some items and placed the order locally, but the master database now says that you don't have enough of that item to fulfill the order; what are you going to do?
This space for rent
|
|
|
|
|
Hi,
I am very much new to the csharp. In one application there a List control is present in a grid. I need to drop down the list control(this is sync fusion list control) items and show it with a enter key stroke. Please suggest
|
|
|
|
|
|
Hello community,
how can I get the selected Item of my custom picker?
I'm facing the problem for hours but have no further idea on how to fix it.
I need the selected value after clicking on the DoneBtn.
test = label.Text; delivers the right value sometimes, but mostly not.
Thank you in advance!!
Class PickerRendererIos.cs :
[assembly: ExportRenderer(typeof(MyPickerRenderer), typeof(PickerRendererIos))]
namespace DigitalNatives.iOS
{
public class PickerRendererIos : PickerRenderer, IUIPickerViewDelegate
{
IElementController ElementController => Element as IElementController;
public String test = "";
public PickerRendererIos()
{
}
[Export("pickerView:viewForRow:forComponent:reusingView:")]
public UIView GetView(UIPickerView pickerView, nint row, nint component, UIView view)
{
UILabel label = new UILabel
{
TextColor = UIColor.Blue,
Text = Element.Items[(int)row].ToString(),
TextAlignment = UITextAlignment.Center,
};
test = label.Text;
Console.WriteLine(Element.Items[(int)row]);
return label;
}
protected override void OnElementChanged(ElementChangedEventArgs<Picker> e)
{
base.OnElementChanged(e);
if (Control != null)
{
UIPickerView pickerView = (UIPickerView)Control.InputView;
pickerView.WeakDelegate = this;
pickerView.BackgroundColor = UIColor.White;
}
if (e.OldElement != null)
{
var toolbar = (UIToolbar)Control.InputAccessoryView;
var doneBtn = toolbar.Items[1];
doneBtn.Clicked -= DoneBtn_Clicked;
}
if (e.NewElement != null)
{
var text = e.NewElement.SelectedItem;
var toolbar = (UIToolbar)Control.InputAccessoryView;
var doneBtn = toolbar.Items[1];
doneBtn.Clicked += DoneBtn_Clicked;
}
}
void DoneBtn_Clicked(object sender, EventArgs e)
{
Console.WriteLine("Clicked!!!!");
Element.SelectedItem = test;
}
}
}
|
|
|
|
|
ChristopherLeon wrote: delivers the right value sometimes, but mostly not. Add some debug code to your picker to see what values it is dealing with. Use your debugger to step through the code and see what is happening when the result is incorrect.
|
|
|
|
|
I tried a lot of things.
This is the XAML file where the custom picker is defined:
<local:MyPickerRenderer x:Name="PositionPicker" Grid.Row="2" Grid.Column="1" Grid.ColumnSpan="2" Margin="0,6" Style="{StaticResource TextBox}" VerticalOptions="Start" SelectedIndexChanged="Handle_SelectedIndexChangedPositionPicker" SelectedItem="{Binding SelectedPosition, Mode=OneWay}">
<local:MyPickerRenderer.Items>
<x:String>element 1</x:String>
<x:String>element 2</x:String>
<x:String>element 3</x:String>
<x:String>element 4</x:String>
<x:String>element 5</x:String>
<x:String>element 6</x:String>
<x:String>element 7</x:String>
<x:String>element 8</x:String>
<x:String>element 9</x:String>
<x:String>element 10</x:String>
<x:String>element 11</x:String>
<x:String>element 12</x:String>
<x:String>element </x:String>
</local:MyPickerRenderer.Items>
</local:MyPickerRenderer>
I think that the method
SelectedIndexChange is overridden by the custom renderer
local:MyPickerRenderer
Is it possible to access this method again?
Actually
SelectedIndexChanged="Handle_SelectedIndexChangedPositionPicker gives no output:
(Code in the associated .cs file)
void Handle_SelectedIndexChangedPositionPicker(object sender, System.EventArgs e)
{
Console.WriteLine(PositionPicker.SelectedItem);
}
|
|
|
|
|
You assign test only in the GetView method. This is the method that is creating your view. Normally, you would change the value in the Selected override.
This space for rent
|
|
|
|