Fixing Match Exception for multi-line procedure descriptions

[beattyph]

Hi:

I am writing regarding Open Dental Version: 7.6.38 (revision 6320).

I'd like to request the following change to the version controlled source code in a future revision:

File: ContrApptSingle.cs, line 492
revision 6320:

Code: Select all

Match m=Regex.Match(lines[i],"^<span color=\"(-?[0-9]*)\">(.*)$");

requested:

Code: Select all

Match m=Regex.Match(lines[i],"^<span color=\"(-?[0-9]*)\">(.*)");

In other words, I have removed the trailing $ in the regular expression. I have done this for our build, but don't want to fork the code.

Rational:
My wife is running this version of Open Dental in her office in Ontario, Canada. As the Canadian procedure codes in the Canadian Open Dental were incomplete, I wrote a python script that took advantage of tesseract OCR to automatically generate an XML file of procedure codes for Open Dental from a scanned ODA fee guide. This worked great, but some of the procedure code descriptions span multiple lines (have newline, \n, characters in them). Except for the one case that is the topic of this post, we have found that this works fine in Open Dental so far. However, when the appointment module view is set to take advantage of the ProcsColored case, it causes an exception to be thrown because the regular expression in line 492 doesn't match. I'm not an expert on Open Dental, but I don't see why one needs to enforce the match to the end of the input. Regular expressions are greedy, so the output should be the same for inputs that do not have a newline character, whereas for multi-line procedure code descriptions the regular expression will just grab the first line, which we consider reasonable behavior, and (more importantly) will still produce a valid match and not throw and exception.

Thanks so much,

Philip

[beattyph]

In Version 12.2, this is now in OpenDentBusiness/UI/ApptSingleDrawing.cs line 326.

It would still be very nice if the regular expression could be fixed in the main version controlled source. Until then, I'll just maintain my own branch.

[jordansparks]

Doesn't this just seem like a database issue? Can't you just write a quick query to strip \n out of procedure descriptions? We wouldn't allow that character in through our UI, so you shouldn't allow it in through your import tool. I suspect that it creates other problems as well.

[beattyph]

Hi Jordan:

Thanks for your reply; yes --- stripping out the newline characters would be one way to go.

Personally, I prefer changing the regular expression for the following reasons:

1. I used the import tool that is part of Open Dental --- I just created an XML file. If a newline character causes the program to throw an unhandled exception, then the XML import tool should probably include an error check to not let the newline character get into the database in the first place. This seems like more work than just changing the regular expression.

2. I don't see a downside to removing the trailing '$' to match to the end of the string. If the procedurecode.Descript field doesn't have any newline characters, removing the '$' doesn't change the behavior. On the other hand if there are newline characters, it causes an unhandled exception.

3. Multi-line procedure codes show up in multi-line format in the Progress Notes. This makes longer descriptions very easy to read. We don't want to lose this feature --- a feature that maybe we inadvertently created

4. We have been running with this fix for a year and we haven't seen any other issues.

If you decide not to change the main branch, that is fine --- I don't really have a problem maintaining my own branch. This is such a unique and great thing about Open Dental --- I can make a source code change if we prefer a different behavior. So --- thanks so much for creating such a great software tool.