You are in: "ARDS Features", "ARDS as Software" page


ARDS as Software


From programming point of view, software should:

  • do whatever it suppose to do
  • be well documented
  • provide friendly and powerful help
  • be easy understandable for FUTURE SUPPORT

    • Most of existing control office applications are mixture of different programming languages and tools (such us C/C++, MS Visual Basic 6, MS Visual Basic .NET, JavaScript, VBScript, HTML, different versions of MS Visual Studios, MS Excel, MS Access, MS SQL Server, plain text files, etc.), which make nightmare when codes needs to be changed and debugged. We are calling this style "cowboys style".


    We created ARDS by using completely different idea. Here is list of tools and languages we are using:

  • MS Windows 10 (64 bit) operating system
  • MS Visual Studio 2012, C#, WPF (Windows Presentation Foundation) application type
  • Xceed.Wpf.Toolkit controls, Version 2.2.0.0, Runtime Version v4.0.30319
  • .NET Framework Version 4.7.02556
  • MS SQL Server 2008 R2 database for data storage
  • SQL stored procedures for saving/retrieving data to/from database


    • As you can see, we are using two languages: C# for coding, and SQL for saving/retreiving data to/from database.

  • We are using one database
  • We are using one MS Visual Studio version
  • We are using one application's type



    • ARDS execution has only one ARDS.exe file, and has one ARDS.ini file. In ini file we are storing database connection string, and multilingual settings for Login form. Ini file is encrypted for security reason. Here is part of ARDS.ini file:



    Software is pretty well documented, we put lots of comments inside codes. This is helping for easy understanding what (and more important WHY) we are doing this or that thing.


    Each function has try-catch-finally blocks.


    Software has powerful errors trapping, which is extremally helpful for debugging and future support.
    Each error has it's own Error Code, Date/Time stamp when error happened, module name, function name, error description, stack trace.
    Showing stack trace is reducing time to find exact place where error happened, and fix it.
    When error is happened, error snapshot and error description can be send to designated e-mail address.


    Appication using lots of information messages to allow End User to work with application in easy way.


    Up to now we are encrypting User Name and Password, and data in Application Settings table. Encryption can be easy applied for ALL data.


    We are not running any SQL from codes, we are using parametrized stored procedures to store/retrieve data to/from database.
    Our stored procedures are simple (strict insert/update/delete with possible inner joins), because we spent lots of time with developing database schema.
    Application has designated "clsDBHelper" class for database manipulations.


    We are using delegates for events notifications between classes.



    Please use menus on top of this page to find more information about ARDS.