|
Thanks, I would taken a much more difficult approach.
That is embarrassingly simple.
|
|
|
|
|
smesser wrote: Unfortunately, you also can't depend on the tags having no spaces with the colons (i.e. VIN :, vs YRMD:.
Perhaps you could replace " :" with ":" to fix that and make processing easier.
After that, if values don't contain SPACEs then you can split on SPACE and then on colon as mentioned.
Certainly a Regular Expression could be used if the data is regular enough, but why not perform both tasks at once?
|
|
|
|
|
Yes, I had just tried that myself.
That one was looking me right in the face.
|
|
|
|
|
smesser wrote:
All can be variable length and there isn't a delimiter
Unfortunately, you also can't depend on the tags having no spaces with the colons (i.e. VIN :, vs YRMD:.
This is true, which makes parsing strings like that pretty hard. I did however find a pattern in this string, but it doesn't necessarily mean that it holds true for other strings.
Basically it's always a pair of arbitrary strings separated by a colon, sort of like a key/value-pair.
So whenever there's a whitespace left (or also right?) to the colon it doesn't count as a delimiter.
Based on this fact the following regex will work:
[^\ ]+\ *:[^\ ]+
If you want to also disallow whitespaces right to the colon as a delimiter then this will work:
[^\ ]+\ *:\ *[^\ ]+
regards
modified 12-Sep-18 21:01pm.
|
|
|
|
|
Then what use named groups to get your values?
EDIT:
private void Test9()
{
string original = "LIC#:ABC123 YRMD:03 MAKE:CHEV BTM :CP VIN :1G1JC12F137230800";
Regex r = new Regex(@"[^\ ]+\ *:\ *[^\ ]+");
MatchCollection theMatches = r.Matches(original);
foreach (Match theMatch in theMatches)
{
Console.WriteLine(theMatch.Value);
}
}
modified on Friday, March 21, 2008 12:42 PM
|
|
|
|
|
This seems to work
if ( args.Length > 0 )
{
System.Text.RegularExpressions.Regex reg = new System.Text.RegularExpressions.Regex
(
@"^\s*LIC#\s*: (?'LIC'.*)YRMD\s*: (?'YRMD'.*)MAKE\s*: (?'MAKE'.*)BTM\s*: (?'BTM'.*)VIN\s: (?'VIN'.*)$"
) ;
foreach ( System.Text.RegularExpressions.Match mat in reg.Matches ( args [ 0 ] ) )
{
System.Console.WriteLine
(
"LIC# = {0} YRMD = {1} MAKE = {2} BTM = {3} VIN = {4}"
,
mat.Groups [ "LIC" ].Value
,
mat.Groups [ "YRMD" ].Value
,
mat.Groups [ "MAKE" ].Value
,
mat.Groups [ "BTM" ].Value
,
mat.Groups [ "VIN" ].Value
) ;
}
}
Dagnabit! Frowny faces?! Who wrote this crap?
I added a SPACE between the : and the ( to solve that little problem, but they should be eliminated from the Regex.
modified on Friday, March 21, 2008 1:52 PM
|
|
|
|
|
PIEBALDconsult wrote: Dagnabit! Frowny faces?! Who wrote this crap?
Paging Chris Maunder.
Otherwise [Microsoft is] toast in the long term no matter how much money they've got. They would be already if the Linux community didn't have it's head so firmly up it's own command line buffer that it looks like taking 15 years to find the desktop.
-- Matthew Faithfull
|
|
|
|
|
Hum, unless the copy paste messed something up this is not creating a match for me.
|
|
|
|
|
With the SPACE between the : and ( you need to use
System.Text.RegularExpressions.RegexOptions.IgnorePatternWhitespace
to ignore the extraneous SPACEs, but then the # and everything after it become a comment!
So now I've escaped the the # to \x23 .
Resulting in:
System.Text.RegularExpressions.Regex reg = new System.Text.RegularExpressions.Regex
(
@"^\s*LIC\x23\s*: (?'LIC'.*)YRMD\s*: (?'YRMD'.*)MAKE\s*: (?'MAKE'.*)BTM\s*: (?'BTM'.*)VIN\s: (?'VIN'.*)$"
,
System.Text.RegularExpressions.RegexOptions.IgnorePatternWhitespace
) ;
Whoops, I had left out an asterisk I had meant to include: VIN\s*
modified on Friday, March 21, 2008 2:35 PM
|
|
|
|
|
Quick little edit to get rid of the extra space that was being captured.
^\s*LIC\x23\s*: (?'LIC'.*)\sYRMD\s*: (?'YRMD'.*)\sMAKE\s*: (?'MAKE'.*)\sBTM\s*: (?'BTM'.*)\sVIN\s: (?'VIN'.*)$
|
|
|
|
|
Hey, I was leaving that for the OP to do; I didn't want to solve the whole thing for him.
|
|
|
|
|
Sorry, I was bored and happened to have The Regulator open. At least now I can enjoy the weekend in knowing that I accomplished something today.
|
|
|
|
|
Thanks all, your comments and examples have been very inlightening
modified on Friday, March 21, 2008 6:15 PM
|
|
|
|
|
|
Hi all,
I was just wondering about the following problem. I often write device drivers for various hardware systems. Often I put all that code in a DLL which can be called by another program. Usually I'll need to put in a form somewhere to allow the user to change parameters and settings. Normally this form is in the program that accesses the dll which is all well and good.
Thats all fine, but I got to wondering does anyone know how to put a windows form with buttons and stuff inside a dll? Could I use the forms editor like I would If I was producing an exe or would I have to hard code everything?
Its just that I figured it would lead to a much more modular and potentially better design because all the configuration and control is in one place.
|
|
|
|
|
Just create a C# Class Project and create your forms there, as per normal.
|
|
|
|
|
That was quick! So literally it is just as simple as the process for writing a new exe file then. Thanks I'll have to try it.
|
|
|
|
|
Thanks I tried it and it works just fine.
I needed to simply add a form to the dll class and add a method inside the dll that shows the form. Another program can simply call the method inside the dll to display to form. - Thats just great.
|
|
|
|
|
I've been rummaging around in nUnit and experimenting with it, and I have a question about properly using it.
It seems to me that it's only real purpose is to test discrete functions and classes, and really isn't applicable for testing the application that uses the "units". Am I just missing something?
Next, I understand that TDD is supposed to promote the building of tests before doing the actual coding, but what about adding nUnit to existing code? It seems kinda pointless unless you're doing a ground-up redesign of your code.
I've been a programmer for almost 30 years, and didn't really understand the reasoning behind "extreme programming", and think "agile programming" is the sure path to failure in a production product. TDD makes a lot more sense in theory because you have to have a good design up front in order to write applicable/viable tests, which leads (theoretically) to better core code sooner in the process.
Please be gentle in your protestations and guidance - remember, I'm REALLY new at this TDD stuff.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997 ----- "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Hi John,
first of all, wrong forum. Your message does not contain a single C# item
I have been using nunit occasionally, and yes I too think it is more suited for
testing the lower levels of a program, a library, the business logic, etc;
and less for a GUI, or an entire app.
That does not change the value of TDD though, it only tells me we may need or want
other tools as well.
Luc Pattyn [Forum Guidelines] [My Articles]
This month's tips:
- before you ask a question here, search CodeProject, then Google;
- the quality and detail of your question reflects on the effectiveness of the help you are likely to get;
- use PRE tags to preserve formatting when showing multi-line code snippets.
|
|
|
|
|
Luc Pattyn wrote: first of all, wrong forum. Your message does not contain a single C# item
I knew I shoulda brought a gun to this party...
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997 ----- "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
John Simmons / outlaw programmer wrote: and didn't really understand the reasoning behind "extreme programming", and think "agile programming"
AFAIK, these are successful when you are doing an application which don't have a proper requirement specification in hand. If you have the complete requirement and design document with you, then these are kinda pointless. Concept is, when new changes are made to the system, automated tests will ensure everything else is functioning correctly.
I tried this approach and liked it very much. The project which I worked don't have complete requirements when I started it. So I created test cases for the functionalities which I wrote. When I get new requirements, I were able to make changes without looking to the other parts of code, automated tests will fail if the new change is affecting somewhere.
Hope this makes sense
|
|
|
|
|
John Simmons / outlaw programmer wrote: it's only real purpose is to test discrete functions and classes
That is my understanding as well. Which isn't necessarily a bad thing.
John Simmons / outlaw programmer wrote: adding nUnit to existing cod
The only way that this would make sense to me is if you added unit testing on an 'as needed' basis and not try and add unit testing to the entire code base. Evolve it over time.
Why is common sense not common?
Never argue with an idiot. They will drag you down to their level where they are an expert.
Sometimes it takes a lot of work to be lazy
Individuality is fine, as long as we do it together - F. Burns
|
|
|
|
|
Well not surprisingly I don't agree with the replies you have so far received.
John Simmons / outlaw programmer wrote: It seems to me that it's only real purpose is to test discrete functions and classes
NUnit is for Unit testing and discrete functions, classes and modules are the primary purpose of Unit Testing. You can however expand that meaning and the use of NUnit to be pretty much whatever you want. However I don't believe that attempting to do system testing or regression testing with Unit test tools is a very productive way to do those types of testing.
John Simmons / outlaw programmer wrote: Next, I understand that TDD is supposed to promote the building of tests before doing the actual coding
Yes, um, No, well maybe. It's like with any other process, they should be tailored to your individual environment and project.
John Simmons / outlaw programmer wrote: but what about adding nUnit to existing code?
You don't "add" NUnit to your system code. If that is what you are doing you are doing it wrong.
John Simmons / outlaw programmer wrote: It seems kinda pointless unless you're doing a ground-up redesign of your code.
No you can certainly write NUnit Unit tests for existing apps without modification to the application code base.
NOTE: We tend to put all NUnit tests in a "Test" project as part of the Solution.
John Simmons / outlaw programmer wrote: I've been a programmer for almost 30 years
Oh dear, what happened to you?
John Simmons / outlaw programmer wrote: didn't really understand the reasoning behind "extreme programming", and think "agile programming" is the sure path to failure in a production product.
The rise in popularity, as with anything in our profession, causes much abuse and misuse due to assumptions that people know what it means. Mostly they don't. There was a common struggle regarding requirements. Some assumed you should have them all before starting development. We know of course know that is very very rare as requirements almost always constantly change. Agile was borne as an attempt to standardize the fact that requirements almost always change during the original development cycle of a project. There are many different prescribed agile processes and most of them share one common trait. That you tailor the process to your environment and project. Easy to type, not so easy to do.
I have been a programmer for almost 20 years now and I have always done Unit tests. Not always test drive, and certainly not with tools like NUnit that make it a real breeze to do. I still don't do test driven in a Nazi like fashion but I agree that thinking or even writing test (in some cases) can be helpful to your thought process about designing and developing your project.
One of the most productive aspects of having Unit Tests as early as possible is that when requirements do change you can update the module and run all those tests to ensure you haven't broken anything.
Well you have probably stopped reading by now so I guess that's enough.
led mike
|
|
|
|
|
nUnit can be used with existing projects. Anytime you change code writing unit tests really helps with the testing to identify errors. You will find, however, that writing good tests cases requires a lot of time. Sometimes when I have really bad code a unit test is the only real way to identify the errors.
Also, if you find yourself testing the results from a database call you are using unit testing wrong and have slipped into integration testing which is different and the two shouldn't be mixed.
I ramble a lot, unit tests do not test the application just the code. The theory is that if your code works as promised your application is more likely to work as expected. You still need traditional testing even with the best TDD.
Need a C# Consultant? I'm available.
Happiness in intelligent people is the rarest thing I know. -- Ernest Hemingway
|
|
|
|