|
Nishant S wrote:
This won't work when there is no tcode attribute at all.
Ah, gotcha, I'm a little  Glad you have it working. 
-Nick Parker
|
|
|
|
|
|
Okay. It needed a space.
The correct pattern to use is :-
string pattern = "type[^>]+ (tcode='(?<code>[\\S]+)')?[^>]*>";
I am still a little scared though as to whether even this might have some hidden issues.
Nish
|
|
|
|
|
thats correct - looks like you need a space when tcode is there, I would suggest you make the space part of the optional tcode bit...
string pattern = "type[^>]+( tcode='(?[\\S]+)')?[^>]*>";
"When the only tool you have is a hammer, a sore thumb you will have."
|
|
|
|
|
I have 20 textboxes. Lets say, they are txtbox1 to txtbox20
Now, I would like to check them one by one if their text is null.
If txtbox1.Text is null, i would stop checking the other textboxes right away. I can easily perform this using an if-else but, its not gonna be that readable. So I want to use a switch statement. The problem is, how?
Please help. 
"To teach is to learn twice"
|
|
|
|
|
daljv wrote:
So I want to use a switch statement. The problem is, how?
Why not just do soomething like this:
ControlCollection col = (ControlCollection)this.Controls;
foreach(Control t in col)
{
if(t is TextBox)
{
if(t.Text != String.Empty)
{
break;
}
}
}
-Nick Parker
|
|
|
|
|
Nick Parker wrote:
ControlCollection col = (ControlCollection)this.Controls;foreach(Control t in col){ if(t is TextBox) { if(t.Text != String.Empty) { // Do something here. break; } }}
Hmmm...
I can't help myself....
1~ he wanted to stop as soon as one text box had no text (actually he mentioned only the first text box, but I'll assume it was an example).
Thus
<br />
if(t.Text == String.Empty) break;<br />
Also, why not keep your own collection of controls containing only the text boxes so that you would not have to parse through all of the controls in the form?
Actually, since they are all text boxes, make it a collection of text boxes...
So, when you add them to the form's Controls in your initializer, also add them to myBoxes;
then:
<br />
foreach(TextBox t in myBoxes)<br />
{<br />
if(t.Text == String.Empty) break;<br />
}<br />
HTH,
F.O.R.
|
|
|
|
|
Frank Olorin Rizzi wrote:
if(t.Text == String.Empty) break;
Woops, I guess I flip-flopped that.  Ah well, I think he got the main idea which was important.
Frank Olorin Rizzi wrote:
Also, why not keep your own collection of controls containing only the text boxes so that you would not have to parse through all of the controls in the form?
Because then he would have to maintain that collection where as the Form already maintains a collection of all controls applied to it. This is more extensible and easier to maintain. Granted there are other ways to do this, they simple require more work and don't provide much more in the efficiency department. 
-Nick Parker
|
|
|
|
|
Nick Parker wrote:
Because then he would have to maintain that collection where as the Form already maintains a collection of all controls applied to it. This is more extensible and easier to maintain. Granted there are other ways to do this, they simple require more work and don't provide much more in the efficiency department.
This argument lacks, if there are more text boxes in th esame form...
Roland Bär
|
|
|
|
|
Roland Bär wrote:
This argument lacks, if there are more text boxes in th esame form...
Show me an example please.
-Nick Parker
|
|
|
|
|
Sorry, not precice enough ...
if you have the 20 textboxes, that should be tested, and then also other textboxes in the same form, that should not be checked, it is better to have the 20 textboxes in an own collection. Like this you can iterate over your collection without checking if it is a textbox to be checked or not.
Hope it is clear what I mean. 
greets
Roland
|
|
|
|
|
Roland Bär wrote:
if you have the 20 textboxes, that should be tested, and then also other textboxes in the same form, that should not be checked, it is better to have the 20 textboxes in an own collection. Like this you can iterate over your collection without checking if it is a textbox to be checked or not.
There are other ways around your problem, however my answer still identifies how to accomplish what he was asking for.
-Nick Parker
|
|
|
|
|
Nick Parker wrote:
Because then he would have to maintain that collection where as the Form already maintains a collection of all controls applied to it
hmm.. yes, I see what you mean.
...speaking of which, let me ask this:
If I picked the TextBox object that gets added to the Form's Controls collection (say it is named tBox1), and simply add it to my own collection (say an Hashtable) like so:
myTable.Add(myTable.Count, tBox1);
Wouldn't I be adding just a reference?
Thus the impact on the memory would be relatively small?
Or am I missing something here?
|
|
|
|
|
There are many ways in which you can tackle this, depending on the exact circumstances you should consider using a specific method. My method is rather abstract.
-Nick Parker
|
|
|
|
|
this won't work - t is TextBox, t would still be a Control which does not have a .Text field so use "as".
also why are you casting this.Controls? its a ControlCollection already...
foreach(Control t in this.Controls)<br />
{<br />
TextBox tb = t as TextBox;<br />
<br />
if(tb != null && tb.Text == String.Empty)<br />
{<br />
break;<br />
}<br />
}
"When the only tool you have is a hammer, a sore thumb you will have."
|
|
|
|
|
Philip Fitzsimons wrote:
this won't work
Yes, it will, try it.
Philip Fitzsimons wrote:
also why are you casting this.Controls? its a ControlCollection already...
Test your code, it will fail if you don't cast it, mine did, I previously wasn't casting it.
-Nick Parker
|
|
|
|
|
I can't see who it would work - it won't work on my computer...
"t" is a Control.
"t.Text" is not valid on a Control.
how does it compile?
"When the only tool you have is a hammer, a sore thumb you will have."
|
|
|
|
|
Philip Fitzsimons wrote:
how does it compile?
Drop my code onto a form, it works. 
-Nick Parker
|
|
|
|
|
no it does not:
error CS0117: 'System.Web.UI.Control' does not contain a definition for 'Text'
"When the only tool you have is a hammer, a sore thumb you will have."
|
|
|
|
|
Philip Fitzsimons wrote:
no it does not:
Ah, I see you are doing this on an ASP.NET webform. This works on a Windows Form. 
-Nick Parker
|
|
|
|
|
"When the only tool you have is a hammer, a sore thumb you will have."
|
|
|
|
|
Hi all, this is kind of an architecture question:
I'm in the initial stages of designing a commercial app that is ported from c++ to c# (rebuilt actually) and want to use business objects that can be used both remotely and locally (the old app was local only, this is a new thing). (I.E. a user may install in network server mode or single computer mode)
I'm very new to remoting, just getting my feet wet and am wondering in this situation how to go about this.
I don't want to duplicate any code if possible.
How would you suggest creating a business object that can both be remote or local without having to change the source code for the objects themselves?
(Possibly not inherit from MarshalByRefObject in the case of being local but do inherit from MarshalByRefObject in the case of being remote?)
------------
Tomorrow is the same day as today was yesterday.
|
|
|
|
|
Hi,
You should take a look at VB.NET Business Objects by Rocky Lhotka. (Yes, it's VB.NET, who cares, it's easy enough to convert to C#!)
All the info you need is there, plus you get the CSLA.NET framework for free! It has even been translated into C#...
Very good book! You'll love it!
|
|
|
|
|
Looks ideal, thanks!
Now if I hadn't just blown my book budget on those UML books...
------------
Tomorrow is the same day as today was yesterday.
|
|
|
|
|
Inheriting from MarshalByRefObject doesn't hurt anything if you're not using remoting. Heck, almost everything in the Windows Forms does! (those that inherit from Control, which inherits from Component, that inherits from MarshalByRefObject). It that way with any OO design and inheritance - only use what you want to. It's field values that take up space in memory - not a gazillion methods and properties. And such methods and properties won't do anything unless they're called. Heck, most of those controls aren't even remoting because they're not serializable (although you could either implement an ISerializationSurrogate for them, or extend them and mark your control as [Serializable]).
The best place to put such an object is in an assembly that both the client and server share, such as the one where the remoting interface is (assuming you're doing it that way, and you might as well since you are using a shared assembly now - it makes for easier maintainence rather than generating a new one using soapsuds.exe or something when you change your remoting object).
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
