|
I had a dig around and couldn't find anything in particular for £ signs - so I created this quick stub and it is working as expected for me
XmlDocument doc = new XmlDocument();
XmlNode node = doc.CreateNode(XmlNodeType.Element, "PoundTest", "Dummy");
node.InnerXml = "£";
doc.AppendChild(node);
doc.Save(@"c:\dummy.xml");
which outputs
<PoundTest xmlns="Dummy">£</PoundTest>
|
|
|
|
|
Hmm, the issues I am having are in an attribute and I am using XDocument rather than XmlDocument.
It's interesting yours works though
|
|
|
|
|
Sorry misread the XDocument bit, just added this to my original stub and it still works though
XmlAttribute elem = doc.CreateAttribute("PoundAttribute");
elem.Value = "£";
node.Attributes.Append(elem);
to give
<PoundTest PoundAttribute="£" xmlns="Dummy">£</PoundTest>
|
|
|
|
|
Thanks. Time to scrap XDocument then 
|
|
|
|
|
Here you go
XDocument doc = new XDocument();
XElement node = new XElement("PoundTest", "");
XAttribute attrib = new XAttribute("PoundAttribute", "£");
node.Add(attrib);
doc.Add(node);
doc.Save(@"c:\dummy.xml");
which gives
<?xml version="1.0" encoding="utf-8" ?>
<PoundTest PoundAttribute="£" />
|
|
|
|
|
That works for me too.
Curiouser and curiouser.
Thanks for your help
|
|
|
|
|
Glad I could help - I lived just outside Garforth for 8 years and had many a good night out in Leeds 
|
|
|
|
|
Party central is Leeds although it's a long time since I used to haunt the Phono and the Warehouse
|
|
|
|
|
You helped to fix it. You showed the problem wasn't in XML but in the StreamReader I am using to read the data I build into XML - you have to set Encoding on the StreamReader to Encoding.Default - apparently the default isn't Encoding.Default - Bah!!!
|
|
|
|
|
Haha yeah I've tripped over this one a few times. The default is UTF8, I believe. Took me a while to work out that to read a Windows-ANSI file (what most of us actually have on our disks) you have to set it to Default explicitly.
|
|
|
|
|
The default it provides isn't default enough apparently 
|
|
|
|
|
It's high-bit so you need to encode it, but the XDocument should do that for you (and Reiss's answer would seem to indicate that that is already the case). The named entity is £ but that only applies in HTML, in XML you would have to use £ or set the declared document encoding to ISO-8859-1 (if there are no 2-bit characters) or UTF-8 (encoding the high bit characters appropriately) in the XML header.
|
|
|
|
|
It took Google years to fix it, finally, (as of this week, they did)
|
|
|
|
|
Hai,
Please take a look my code
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Runtime.InteropServices;
using System.Data;
using System.Drawing;
using System.Text;
using System.Windows.Forms;
namespace Combo
{
public class Combo
{
private System.Windows.Forms.ComboBox li = new System.Windows.Forms.ComboBox();
public event EventHandler SelectedIndexChanged;
private object[] eventObject;
public void Addselect(Control FormName, string name, int top, int left, int width, int height, string Text)
{
li.Top = top;
li.Left = left;
li.Width = width;
li.Height = height;
li.Name = name;
li.FlatStyle = FlatStyle.Flat;
li.Text = Text;
li.IntegralHeight = false;
li.MaxDropDownItems = 5;
li.DropDownStyle = ComboBoxStyle.DropDown;
li.Size = new System.Drawing.Size(136, 81);
li.BackColor = System.Drawing.Color.DarkGray;
FormName.Controls.Add(li);
eventObject = new object[] { this, "SelectedIndexChanged" };
li.SelectedIndexChanged += new EventHandler(li_SelectedIndexChanged);
}
private void li_SelectedIndexChanged(object sender, EventArgs e)
{
if (SelectedIndexChanged != null)
{
SelectedIndexChanged(eventObject, null);
}
}
public bool Enabled
{
get { return li.Enabled; }
set { li.Enabled = value; }
}
public bool Visible
{
get { return li.Visible; }
set { li.Visible = value; }
}
public void Addtocombobox(string [] arguments )
{
li.Items.AddRange(arguments);
}
public int sindex()
{
int index;
index = li.SelectedIndex;
return index;
}
}
}
The problem is
public int sindex()
{
int index;
index = li.SelectedIndex;
return index;
}
when i try to return the selected index of combobox i got error here please hep me to do fix this error
This is my error please take a look this
Error 1 Since 'Combo.Combo.sindex()' returns void, a return keyword must not be followed by an object expression F:\SelectboxLibrary\SelectboxLibrary\Class1.cs 65 13 SelectboxLibrary
i dont know what is the error
Anyone Please help me?
Arunkumar.T
|
|
|
|
|
No, the problem is not in sindex(). It is in F:\SelectboxLibrary\SelectboxLibrary\Class1.cs, line 65.
- What's the code there?
- How is Combo.Combo linked with that project? I.e. is an older version of Combo.Combo used by Class1 - a version where sindex() is public void sindex()?
|
|
|
|
|
Thankyou for your replay
iam trying to create a library of combobox the code shown above is the class1.cs file. of-course there are no other file in my project.
Thank you
Arunkumar.T
|
|
|
|
|
Where does this error message come from, compiler or linker? And which compiler are you using?
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
hi
i need implementation shamos algorithme with C# ?
|
|
|
|
|
Well I'm sure you will be able to find it with a little help from your friend Google.
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
0. I ask you to "cut me some slack" here for presenting a trivially bare-bones code example for the sake of brevity.
0.a. My real-world exploration of this topic is related to exploring various techniques for synchronization of objects and data across Classes and Forms, and evaluating them in the context of projects where there are a lot of objects that need to be synchronized, and WinForms current default binding techniques do not seem to meet my needs.
0.b. I am quite familiar with other techniques for object "injection," and use of exposure of objects ... to 'outside' objects ... by public properties that are set to instances of objects. Exploring casting to 'Interface' in the sense of using it as a "filter" to limit what is exposed to other objects, rather than a "contract for implementation," is a new walk in the dark ... for me (but, my guess is, probably not ... for you).
1. Assume you have a simple Interface, something like:
public interface TheInterface
{
string iText { get; set; }
}2. Assume you have a simple class that implements that Interface
public class SimpleClass : TheInterface
{
public string iText { get; set; }
}3. In SimpleClass there's a method call, where the SimpleClass instance itself is passed as a parameter to a public method in another class:
SomeOtherClass.SomeMethod(this, "some string"); 4. And the method, SomeMethod, has a parameter signature like this:
public void SomeMethod(TheInterface iFace, string someText)
{
iFace.iText = someText;
}5. So in this case you might say that the "casting" of SimpleForm to TheInterface is performed implicitly, rather than explicitly (yes, I am aware it could be cast explictly, and passed as Type TheInterface).
Comment: in the 'real-world' usage I have in mind there would be an internal collection, something like List<TheInterface> which would be enumerated, and changes made to synchronize whatever with the whatever in the 'calling object' cast to TheInterface.
So, my question is: what are the internal "costs" of using this type of conversion: trivial ?
Does this kind of technique emit what devotees of Java so love to refer to as a "bad smell" ?
What method signatures, if any, in this scenario, would you define in an interface ?
I appreciate any comments or guidance !
thanks, Bill
"Last year I went fishing with Salvador Dali. He was using a dotted
line. He caught every other fish." Steven Wright
|
|
|
|
|
The cost of that type of conversion (regardless of whether it's implicit of explicit) will be trivial if you're actually doing anything with the result. It's a bit faster than casting to an abstract base class.
From a quick test: you can do a million of calls to your SomeMethod in 15 to 25 miliseconds.
|
|
|
|
|
Hi Bill,
BillWoodruff wrote: SomeOtherClass.SomeMethod(this, "some string");
there is no cost at all, the compiler checks your code and sees your this indeed conforms to the expected parameter type (TheInterface iFace), so all that happens at run-time is a pointer gets passed, no run-time checking is involved.
It would be exactly the same as passing a TextBox to a method that accepts a Control; the compiler would see how TextBox implements Control, so all is well and free.
|
|
|
|
|
I agree with Luc.
There is no "casting", no "conversion". No bad smell.
|
|
|
|
|
Hi Bill,
I know where you are coming from with this having being involved in some discussion on the same thread.
I agree with the others, there is no cost involved - to answer your question.
Another/different question is should you pass an object (disguised as an interface or not) to another for simplicity of communication between the objects?
Personally, I think not. An interface is a slight improvement to passing a concrete object, but I instinctively feel the 'secondary' object should be raising an event that the 'primary' object can choose to subscribe to or not depending on whatever logic is appropriate, and if subscribed - react or not. If the 'primary' needs to communicate with the 'secondary' then it should retain a reference to it - whether that is as an interface or not is irrelevant.
In other words, I see no particular improvement or benefit between these two, I disapprove of them both equally!
public partial class FormPrimary : Form
{
public FormPrimary()
{
InitializeComponent();
}
public void SetText(string text)
{
Text = text;
}
}
public partial class FormSecondary : Form
{
private FormPrimary primary;
public FormSecondary()
: this(null)
{ }
public FormSecondary(FormPrimary primary)
{
InitializeComponent();
this.primary = primary;
}
private void SetPrimaryText(string text)
{
if (primary != null)
{
primary.SetText(text);
}
}
}
public interface IStuff
{
void SetText(string text);
}
public partial class FormPrimary : Form, IStuff
{
public FormPrimary()
{
InitializeComponent();
}
public void SetText(string text)
{
Text = text;
}
}
public partial class FormSecondary : Form
{
private IStuff primary;
public FormSecondary()
: this(null)
{ }
public FormSecondary(IStuff primary)
{
InitializeComponent();
this.primary = primary;
}
private void SetPrimaryText(string text)
{
if (primary != null)
{
primary.SetText(text);
}
}
}
Just my initial feelings and I am interested to see how this turns out!
|
|
|
|
|
Hi Dave, A most interesting, thoughtful, and much appreciated reply => +5
I have gone through "phases," it seems, in my very humble[1] evolution in programming in C#.
For a while, I seemed focused on 'passing around everything' by raising events, and transmitting data through custom EventArgs.
Then, in my head, I began to feel that there were two "modes" to consider here: one mode was "access:" at times Class/Form/Object A needs to have access to some Field/Property/Data in Class/Form/Object B ... and the principle of "separation of concerns" is the reason why Object A is not designed to be "intimate" with Object B (such as by sharing an Interface, or Inheritance).
And, the other mode, was "raising Events.
I began to think that in terms of this hypothetical "access mode," that the right thing to do was to expose, somehow, in Object B, what Object A "needed to know."
At that point I went into a "phase" where "injection" seemed the right thing to do: plug a reference to the instance of Object B into Object A, and then Object A can "help itself" to everything publicly exposed in Object B.
Then I came to feel that injection was (at least in the broad way I was using it) over-kill, and kind of a violation of separation of concerns. The old security buzz-word "need-to-know" seemed relevant to me here.
Then I entered a phase where I focused on creating static "Manager" classes through which interaction, and exchange of information between Objects/Classes/Forms was handled, in some cases assigning Events to Objects inside the static Manager class, at times just publishing methods in the static Manager class that any Object could invoke, passing in whatever.
And I still like this "static class" Manager idea in a scenario where you may have a whole bunch of run-time created objects of the same type active. For example, a "sticky note" application where you want to modify the content of some, or all, "stickies," based on some action in one particular "sticky."
And, finally, I came to the current phase, which I might call "parsimonious accessibility:" if there's one something in Object B that Object A needs access at times to: then, in Object B, define a Public Property that exposes what Object A needs to know.
Meanwhile, and this may not be a good thing, I seem to have come to rely on Events much less than ever: raising a custom event only when its directly related to asynchronous user behavior at run-time.
So, right now, the use of Interfaces, as a way to "limit exposure" between Objects is kind of the "new dance craze" for me, since I seem to have under-estimated what interfaces can do. And such interesting possibilities as explicit rather than implicit implementation of interfaces tantalize me[^].
My long-range goal here is simple: to have the depth of knowledge to approach solutions to real-world problems involving both algorithms, and asynchronous UI design, and OO application architecture, with a broad "palette" of techniques for inter- and infra- object communication/access tempered by awareness of the usefulness, efficiency, relevance, and cost/benefits of the varying. In other words, to have some sense of "best practice."
My mind is wide-open, and I'm ready to go "cold turkey" to withdraw from addiction(s) to any "phases."
best, Bill
[1] Picking out any one chapter, and reading, in Jon Skeet's "C# in Action" absolutely tops-up my "humility buffer" !
"Last year I went fishing with Salvador Dali. He was using a dotted
line. He caught every other fish." Steven Wright
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
