|
jschell wrote: Every time you touch it it re-writes the file
Yes, it does.
jschell wrote: Which means that all formatting is lost.
It does mess up the formatting, I'll agree with that. Since it's an XML file, I just hit the "Format Document" button and it fixes it. Not enough of an annoyance to give up the designer editor IMO.
jschell wrote: And all documentation.
You put documentation in your config file? Thats an extremely odd place for documentation seeing as the .config files are NOT meant to be edited manually by end users. They are meant to be edited by people who know what the settings are (i.e. developers, etc).
jschell wrote: guaranteed the have the same ordering between point releases
Last time I checked, XML and .config files were unordered formats. If you are relying on the order of tags in an XML and/or .config file... "ur doin' it wrong".
|
|
|
|
|
SledgeHammer01 wrote: You put documentation in your config file? Thats an extremely odd place for
documentation seeing as the .config files are NOT meant to be edited manually by
end users. They are meant to be edited by people who know what the settings are
(i.e. developers, etc).
No idea what kind of "end users" you have but my end users are Operations and Support personnel. And they are specifically the people that need to edit the configuration values.
Also no idea how you release software but busienss needs often drive new feature releases along, of course with bug fixes. And those can all require configuration values. So changes happen frequently.
Also although it might be nice to have a formal operations manual actually producing that seems to be a problem at most places I work at. And configuration files that have more than just a couple entries require documentation. Which either means putting it in the configuration file or putting it in another file. If it is put in another file then Operations/Support must be told about it. Repeatedly.
And of course to create a actual operations manual means that I, and no one else, would need to produce the documentation in the first place. Far as I am concerned since I know Operations/Support will be looking to the file anyways the documentation that is in there is going to be the source for the formal document anyways.
SledgeHammer01 wrote: Last time I checked, XML and .config files were unordered formats.
Both of those are entirely incorrect.
XML can be unordered or ordered.
And MS config files have some sections that require specific ordering.
But that doesn't have anything to do with what I am talking about...
SledgeHammer01 wrote: If you are relying on the order of tags in an XML and/or .config file... "ur
doin' it wrong".
If if fact that had anything to do with delivering a configuration file then you would in fact be correct. But it doesn't.
The order however does matter when Operations/Support uses standard difference tools to compare configuration files. Such as what they might do when they need to install a new major version or point release and they want to insure production machines have the same values with a new configuration file and the old one.
|
|
|
|
|
jschell wrote: No idea what kind of "end users" you have but my end users are Operations and
Support personnel. And they are specifically the people that need to edit the
configuration values.
Same kind. I've noticed they are often too retarded to manually edit config files, so I usually provide an easy to use GUI for them (or at the very least, send them a whole new config file they just replace the old one with). For applications that go out to end users, asking an end user to change a config file is asking for trouble. Your GUI should do all that.
I know where you're going next... web.configs, web services, etc. don't have GUIs. Well, for a production application, I usually have an admin app or admin portal that controls the system. Much better design.
Also, if you want a simple generic thing, you could do what I did. Have a simple property grid dialog that edits any config file generically and can pull in "documentation" either from an xml file or reflection.
jschell wrote: XML can be unordered or ordered.
Entirely incorrect. The XML spec says specifically that attributes and siblings are unordered and can be returned in any order the parser wants. It just so happens that every parser returns siblings and attributes in document order, but that is NOT guaranteed. If you are relying on something that the XML spec says specifically is not guaranteed, I'd hate to be you when your ops team deploys "XML v17" which has some awesome performance optimization, but no longer returns in doc order and breaks all your stuff.
The proper way to do ordering in an XML file is by using a key.
I will admit however, that it's unlikely that a parser will start returning stuff in non document order, simply because some apps rely on that incorrectly.
jschell wrote: The order however does matter when Operations/Support uses standard
difference tools to compare configuration files. Such as what they might do
when they need to install a new major version or point release and they want to
insure production machines have the same values with a new configuration file
and the old one.
What does this have to do with anything? .NET has this cool versioning thing that automagically updates your config files for you and adds in any missing attributes. Yes, I'll admit that the missing attributes may be added in a different order depending on code path (**UNLESS** you do it correctly -- in which case, the attributes will always be added in the same order).
Is that why you rolled your own .config file system? Simply so your ops team can run windiff on the files to make sure they are identical?
Seems like a proper implementation of upgrading the config files would be a better solution then re-inventing everything and having a non standard API, but thats just me.
|
|
|
|
|
SledgeHammer01 wrote: Much better design.
Nonsense.
SledgeHammer01 wrote: so I usually provide an easy to use GUI for them
Which means you must STILL provide documentation. And a GUI.
So now you have increased the work and time to deliver.
SledgeHammer01 wrote: I know where you're going next... web.configs, web services, etc. don't have GUIs
So you create a GUI, and documentation for the GUI that handles multiple versions for a process that Operations/Support only uses once per install.
Thus quite a bit of additional time and cost - which is your rationalization for ignoring the fact that it rewrites the file?
SledgeHammer01 wrote: Entirely incorrect.
Something new for you to learn...
http://www.w3schools.com/schema/el_sequence.asp[^]
See the first example which says "which must contain the following five elements in order"
SledgeHammer01 wrote: which has some awesome performance optimization,
Yes the high volume tps servers that I have been delivering for the past 15 years do have measured and proven production performance abilities.
SledgeHammer01 wrote: The proper way to do ordering in an XML file is by using a key.
The proper way is to understand more about what "XML" means.
SledgeHammer01 wrote: What does this have to do with anything?
What it has to do with is documentation. Please read what I said. Trivial applications might have config values that are understood without documentation but more complex apps require substantial documentation so someone besides the original developer has any chance of understanding what the values mean, how they should be set, what the relationship between different values, etc.
SledgeHammer01 wrote: ...and having a non standard API, but thats just me.
Yes it is you, because I didn't say anything like that.
|
|
|
|
|
I don't know that the file should be stored in the user's documents directory, it doesn't sound like the right place.
I think a better place is APPDATA (APPDATA=C:\Users\Xxxxx\AppData\Roaming), then you can refer to it as @"%APPDATA%\dbs\latefee.sdf" and then use System.Environment.ExpandEnvironmentVariables before opening it.
It's olde school, like me. 
|
|
|
|
|
Thank you all for dropping all this knowledge on me. It's been a while since I have done any coding, and I am not a programmer by trade. I am in IT for the company I work for, doing mostly tech work (very small business). I write small desktop apps for reporting from our POS system and use C# as I understood it most with VS 2003 (.net 1.1).
As I saw a need to update from XP to Win 7, I am trying to rewrite these programs with .net 4, so I am just now, as a few days ago, trying to learn the new IDE in VS 2010, the new classes and deprecated classes, etc, etc.
Thank you for your understanding and patience. Trying to google and study everything while taking calls all day for every problem from 'the internet is down' to 'this document is not printing correctly' is quite a task.
Again, thanks!
Jude
|
|
|
|
|
hi to all
i have a simple question please tell me,how can i close all methods by shortcut key and collapse all again.yes this is a basic question but i need it and i cant find this shortcut .thanks for help 
|
|
|
|
|
Ctrl M, O
The shortcut is found in Edit->Outlining->Collapse to Definitions in the Visual Studio menu.
I wasn't, now I am, then I won't be anymore.
|
|
|
|
|
|
Sounds like a Visual Studio question, not a C# question.
|
|
|
|
|
How to set the parent form size according to the child form in mdi forms
|
|
|
|
|
In the MDI container form, subscribe to the child form's SizeChanged event:
private void NewChildForm()
{
ChildForm child = new ChildForm();
child.MdiParent = this;
child.SizeChanged += new EventHandler(this.childForm_SizeChanged);
}
private void childForm_SizeChanged(object sender, EventArgs e)
{
Form child = sender as Form;
this.Size = new Size(child.Width, child.Height);
}
Something like that should get the job done. Just adjust the "new Size(int, int)" call accordingly.
djj55: Nice but may have a permission problem
Pete O'Hanlon: He has my permission to run it.
|
|
|
|
|
The "nice" way of doing so is by maximizing the child-form (WindowState wsMaximized)
|
|
|
|
|
Hi all,
i have a aspx grid with checkboxes for selecting the rows. I have some rows seleted and unselected rows also. how i can display only selected rows in the selectedindex_changed event of a dropdown
Thanks
Rk
|
|
|
|
|
Can't your restrict this resultset by controlling the data sent from database? In your select clause to fill this grid, only select the checked ones from the database to begin with?
|
|
|
|
|
Hi,
there is no status for the selected row in the database . this is an aspx grid. i need to hide the unselected rows
Thanks
Rk
|
|
|
|
|
If you don't need the unchecked rows in the datagrid, you can remove them from the datagrid's source as soon as they are unchecked.
|
|
|
|
|
Dear Group,
I am new to DirectX and I am stuck in one basic scenario. So my requirement is -
I am having C# Windows Form. Now on top of that form I have to Slide one Image on top of another Image. Both Images are passed to my this translating class.
I used the concept of Sprite after going through the online Samples. But the problem is when the Sprite is moving the background is set to the color which is provided in the Device.Clear() method. I didn't find any way by which I can overcome this. There is no way to set the background image of the Device too.
I also tried using the concept of Microsoft.DirectX.DirectDraw.Surface too. PFB the code which I tried -
// Code Snippet Begin
SurfaceDescription description = new SurfaceDescription();
description.SurfaceCaps.PrimarySurface = true;
description.SurfaceCaps.Flip = true;
description.SurfaceCaps.Complex = true;
description.BackBufferCount = 1;
m_PrimarySurface = new Surface(description, m_Device);
description.Clear();
description.SurfaceCaps.BackBuffer = true;
m_SecondarySurface = m_PrimarySurface.GetAttachedSurface(description.SurfaceCaps);
description.Clear();
description.SurfaceCaps.OffScreenPlain = true;
m_ImageSurfaceurface = new Surface("MyImage.jpg", description, m_Device);
// Code Snippet End
But here the line -
m_ImageSurfaceurface = new Surface("MyImage.jpg", description, m_Device);
is giving build error without any explanation why.
So I am in a stuck state. Please Help...
Note - I have DirectX 9.0 SDK installed.
Thanks in advance...
Shubhanshu .
|
|
|
|
|
When the receiving side of this serial port is idle, this sending method works just fine...
public static void SendCommandOutTheSerialPort()
{
int Length;
int StartingPosition;
byte[] TheBytesToSend;
Length = TheCommandToTheBox.Length;
StartingPosition = 0;
TheBytesToSend = TheCommandToTheBox;
myPortPool.myPort.Write(TheBytesToSend, StartingPosition, Length);
}
In fact, the Serial port can (and will, and does) send anything just fine.
The moment the external box starts sending us data, this method apparently stops and goes into an eternal loop on the last line.
Stopping the app in debug produces not a yellow arrow on the instruction (i.e., the last one in this method) but a green one instead.
Hovering over that green arrow produces this message..
"This is the next statement to execute when this thread returns from the current function"
I do not understand what thread the debugger has in mind, because I didn't start a thread. The only thing I can think of that even strikes the thought of the word "thread" in my mind is the background event handler that is doing the receive.
Just for good measure, I've set some breakpoints in the event handler that responds to bytes received on that same serial port, and it is properly receiving the bytes from the external box.
In fact, that's how we determined that conflict that was causing this. (We made the external box go silent; never sending any data, so this app can send without any response back.)
If it makes any difference, the send method and the receive method are in different classes.
Thanks for any light on the mystery.
|
|
|
|
|
You need to split your code so that the receiving part runs in a different thread than the sending part. Try a Google search for articles on serial handling for more information.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
If this means that a thread has been started, then this is news to me.
Who started the thread which I was unaware is executing ? How do I find this out ?
Thanks for any clues.
|
|
|
|
|
No it doesn't. As I said, you need to separate the code into two threads, one for sending and one for receiving. At the moment it would appear that your code is single threaded, so as soon as your receive event becomes active, the sending code is blocked.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
Aha, now that is the answer I've been after ! Thank you.
This is not a problem in embedded systems which is where I'm accustomed to just going to the metal and flipping the registers. Gag, this is ridiculously complex.
Thank you for that explanation. It is the light I've been after. Thanks.
|
|
|
|
|
C-P-User-3 wrote: this is ridiculously complex.
I guess it's more because of the architecture of the PC and OS.
C-P-User-3 wrote: It is the light I've been after. Thanks.
You're welcome, I wish all questions were as easy to answer.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
