dblanchard
Senior Member
Posts:185
 |
| 2008-05-18 12:46 AM |
|
At least partially implemented. See this thread for more info...
http://www.clearcanvas.ca/dnn/Community/Forums/tabid/69/forumid/10/tpage/1/view/topic/postid/8283/Default.aspx#8462
|
 Attachment: 080517_ScuPatches.patch
|
|
|
|
steve
Senior Member
Posts:1885
|
| 2008-06-05 10:30 AM |
|
Hi Dan,
I went to apply the patch and realized the Iods were not included in the patch. Would it be possible for you to post in a zip file the Iods?
Thanks,
Steve |
|
| Real-time support available to Clinical Edition and Team Edition customers |
|
|
steve
Senior Member
Posts:1885
|
| 2008-06-05 11:21 AM |
|
Hi Dan,
One other thing, it appears that there are some changes you made to ScuBase that were not included in the patch. Specifically, the GetResultsAsIod() method, which were not included in the patch.
Thanks,
Steve |
|
| Real-time support available to Clinical Edition and Team Edition customers |
|
|
dblanchard
Senior Member
Posts:185
|
| 2008-06-05 11:06 PM |
|
Hi Steve,
Strange, I have been having problems with the patches.
Attached is a zip w/ everything in the CC.DicomServices.Iod namespace and the ScuBase as well... hope that's everything...
regards
|
Attachment: Iods_ScuBase.zip
|
|
|
|
steve
Senior Member
Posts:1885
|
| 2008-06-06 10:56 AM |
|
Thanks Dan for your contributions. I've committed the Iods in changeset 5661. The other code was already committed. I haven't done a real thorough review of everything yet. I'm actually working on some code that will utilize the Find functionality. I'll go through the code a bit more in depth as I do the development work. I'll probably be making changes through the next week or so.
Thanks again for your contribution!
Steve |
|
| Real-time support available to Clinical Edition and Team Edition customers |
|
|
dblanchard
Senior Member
Posts:185
|
| 2008-06-09 09:27 AM |
|
Steve,
Sounds good, the code definitely needs a little more cleanup. Soon I am going to be doing more Modality Worklisting and Performed Procedure Steps, so I will upload patches with any fixes or additions I make...
Regards,
Dan
|
|
|
|
|
steve
Senior Member
Posts:1885
|
| 2008-06-18 10:14 AM |
|
Hi Dan,
I had a few questions about the code I wanted to ask your opinion on. First, I went ahead and reword the PatientQueryIod, StudyQueryIod, SeriesQueryIod, and ImageQueryIod classes so they just define the query tags at each level. I also introduced a QueryIodBase class to to include the base tags that are used at all the levels. With these changes, I'm wondering if we should eliminate the use of the QueryResultIod class for query results, and instead use the level specific classes to store results.
Related to this, I've also thought about introducing a new class that inherits from FindScuBase, and that the PatinetRootFindScu, StudyRootFindScu, and PatientStudyOnlyFindScu classes would inherit from. I would then move some of the results handling code out of FindScuBase, and into the ModalityWorklistScu and this new "ImageFindScuBase" class, so we wouldn't have to use the generic QueryResultsIod class for results. Also, the QueryRetrieveLevel code would be moved out of FindScu, since it isn't needed for modality worklist. The QueryResults property would also be moved into the other classes, where we can make the results be the specific type.
What do you think?
Steve |
|
| Real-time support available to Clinical Edition and Team Edition customers |
|
|
dblanchard
Senior Member
Posts:185
|
| 2008-06-18 01:28 PM |
|
Hi Steve,
1. I don't see a great need for the QueryResultIod, I just included it because I saw the ClearCanvas.Dicom.QueryResult class and wanted that functionality available so people started using the new FindScu. :)
2. I guess it is a bit hard to understand exactly the changes without seeing it, but I think it would be OK, only thing I would worry about is if we are duplicating code in different subclasses, that was one reason why I made all of them inherit from FindScuBase. I guess when doing OOP there is a fine line between re-using functionality and having unused /unneeded code in subclasses.
Thanks for asking my opinion, I trust your judgement for what you think is best.
Regards,
Dan
|
|
|
|
|
dblanchard
Senior Member
Posts:185
|
|
steve
Senior Member
Posts:1885
|
| 2008-06-19 11:12 AM |
|
Hi Dan,
I went ahead and removed the QueryResultIod class. Also, I didn't exactly make the changes as I mentioned above related to FindScuBase. I basically moved the QueryRetrieveLevel out of FindScuBase to just the Patient/Study/PatientStudyOnly FindScu classes, and then I renamed the IsQueryLevelValid() function to ValidateQuery(). As before, the ModalityWorklistFindScu does nothing with this. I thought it was just a bit cleaner this way, since the ModalityWorklist Scu doesn't deal with query levels.
As for the Print SCU patches, I'll create a ticket and apply those next.
Steve |
|
| Real-time support available to Clinical Edition and Team Edition customers |
|
|
steve
Senior Member
Posts:1885
|
| 2008-06-25 06:36 PM |
|
Hi Dan,
Just a quick follow up / FYI. I found a couple of bugs today in the SCU classes in ClearCanvas.DicomServices, whereby an SCU operation could be permanently locked, and not return. Specifically, there were some failure conditions in the dicom library where we were shutting down the connection, but not notifying the user of the API that we shut down the connection. When these failures would occur, the Scu would be stuck/locked.
The problem should be fixed in rev 5993 of the repository, and I'm going ahead and running some tests on this. So, it should be cleaned up now. Note that this could also apply to the StorageScu component or any of the SCUs...
Steve |
|
| Real-time support available to Clinical Edition and Team Edition customers |
|
|
garethashton
New Member
Posts:1
|
| 2009-07-03 02:56 AM |
|
I'm not sure if I am missing a patch or something else but I am getting a null reference error when this get to this line:
basicGrayscaleImageSequence.AddDicomFileValues("fileName");
I have tried passing the "fileName" as both a string path to the DCM file and also as a ClearCanvas.Dicom.DicomFile and same result for both.
Any suggestions? |
|
|
|
|
dblanchard
Senior Member
Posts:185
|
| 2009-07-03 10:48 AM |
|
hi, what is the full exception stack trace? And are you sure the file is a grayscale (PhotometricInterpretation of MONOCHOME1 or MONOCHROME2) image? can you upload an anonymized image for us to test with? |
|
|
|
|
dblanchard
Senior Member
Posts:185
|
| 2009-07-22 11:39 AM |
|
Attached are a few patches, not sure if you want all this in your code base, but thought I'd offer and try to keep our code in synch. You may not want #1, #3.
1 - commented out throwing exceptions in Common.PluginManager otherwise exceptions when using Dicom dll in an exe
2 - added association rejected enum to verify result (VerificationScu)
3 - added abort on NetWorkBase, DicomClient, ScuBase - otherwise, dispose does not work properly
4 - added ScheduledProtocolCodeSequenceList property to ScheduledProcedureStepSequenceIod
5 - updated a few of the dicom attribute Values setters to DicomAttributeMultiValueText (DS, IS)
6 - added AddDicomFileValues(IDicomAttributeProvider dicomAttributes) overload to BasicGrayscaleImageSequenceIod as disccused in this thread:
http://www.clearcanvas.ca/dnn/Community/Forums/tabid/69/aff/10/aft/13299/afv/topic/Default.aspx |
Attachment: 090722_MiscUpdates.patch
Attachment: 090722_PluginManager.patch
|
|
|
|
steve
Senior Member
Posts:1885
|
| 2009-08-03 12:03 PM |
|
Dan,
As always, thanks for the patch. Just as a follow up, from the MiscUpdates patch, most of the changes from this patch have been committed, with the exception of the Abort() handling for Scus. I'm still in process of testing this one out. Concerning the Plugin manager patch, I believe we are going to apply this patch (or else a modified version of it), i just have to do a final check on this with the other developers...
Steve |
|
| Real-time support available to Clinical Edition and Team Edition customers |
|
|
steve
Senior Member
Posts:1885
|
| 2009-09-11 11:43 AM |
|
Dan,
FYI, the plugin related patch has finally been applied (albeit in a different form). We no longer throw an exception when no plugins are present.
Steve |
|
| Real-time support available to Clinical Edition and Team Edition customers |
|
|