Generic SwatInc.Lis.Lis02A02 #5
Comments
|
You are right on this. We need to delete all the branches and maintain a single master branch eh? |
|
I will update this repo soon. Will need your valuable feedback. |
|
Yes , i ll make the test on my side with the new changes , and align |
|
Based on my experience, there are some differences between analyzers implementation even though they are following ASTM standards. I have implemented initially as a standard classes, but realized that doing this will make the code hard to change when there are new analyzers to integrate. In the end, I am changing design to keep different packages/projects for individual analyzers by duplicating record classes. By using this design, I am hoping to make the code base to be extensible and easier to change for individual analyzers without impacting others. I would try to contribute to this repo further if @ibrahimhuycn @J4dJad are considering my proposed design. |
|
Yeah, different manufacturers implement the standard differently so it's kinda difficult to maintain one driver for all. Sometimes the implementation is significantly different. That's the reason the repo currently has multiple main branches. My vision is to have separate drivers/dlls for each analyser and use them as plugins for the interface application. In that case, we'll just have to drop the driver dll file for the required analyser and it should work. I'm not sure what you meant... do you have record types dublicated in the project specific for analysers? Btw... I'm super open to contributions... |
|
Yes, my design is to duplicate records in the corresponding projects of the analyzers. The design is aligned with your vision to keep separate projects that can generate dll file to use in interface application. |
|
<!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.WordSection1
{page:WordSection1;}
-->Salam Aleikum, Here is the Documentation for C311 cobas. Envoyé à partir de Courrier pour Windows De : Ibrahim HussainEnvoyé le :lundi 6 décembre 2021 09:34À : SwatInc/SwatInc.Lis.Lis01A2Cc : J4dJad; MentionObjet :Re: [SwatInc/SwatInc.Lis.Lis01A2] Generic SwatInc.Lis.Lis02A02 (Issue #5) Yeah, different manufacturers implement the standard differently so it's kinda difficult to maintain one driver for all. Sometimes the implementation is significantly different.That's the reason the repo currently has multiple main branches.My vision is to have separate drivers/dlls for each analyser and use them as plugins for the interface application. In that case, we'll just have to drop the driver dll file for the required analyser and it should work.I'm not sure what you meant... do you have record types dublicated in the project specific for analysers?Btw.. I'm super open to contributions...—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications on the go with GitHub Mobile for iOS or Android.
|
|
HI DEAR |
do you still need help @lksgjsj ? |
|
Yes i need.. can you send me your phone on WhatsApp. |
|
🌹🌹🌹 |
|
email me at [email protected] |
|
I send photo no. |
The problem here is that each time we need to adapte the classes - Fields- ( Patient Record , Result record....) to align with the Analyzer spec , but we know that all analyzers using the ASTM protocol are following the same standard means we can create a standard classes following the ASTM starandad, and manage the differences for each Analyzer on the Interface side ( DB or ConfigFile ) tu bypass the not used fields ( If else ).
The text was updated successfully, but these errors were encountered: