Implement existing (but hidden) UI for data range and modify reporting as needed.
This is not the ideal solution to this feature. It would be better to have a pop-up
dialog that asked for beginning and ending dates of range and size of interval for
interval reporting.
Now the loaders imported via the Data menu have access to the
unsupported/untested/brick signals and CHECK_VALUE and UNEXPECTED_VALUE
macros.
Now only devices imported via the oximetry wizard are left out,
since we need to revisit that entire workflow.
Also removed the unused Profile::Import() method.
a New feature has been been added but can not be activated until a UI file is changed - another submission.
This new feature will utilize the current displayed range as the custom range.
Other wise the Overview custom range uses the values from the calendar.
This changes does not require and data or translations.
to act differently from profiles after a subsequent application launch.
It was only getting set at the end of Profile::OpenMachines, which was only
called by the Profile constructor, and which wouldn't succeed on a newly created
profile, having no files to open. Therefore, the only way for the flag to be set
was to quit and re-launch the application after creating the profile.
The flag's only remaining use was to make sure that OpenMachines() wasn't
getting called twice and trampling an existing list of machines, so the check
there was changed from looking at a brittle flag to looking at the actual list
of machines.
A critical warning was also added to the check, since OpenMachines() is
only getting called from the Profile constructor and therefore can't
be invoked twice unless a new bug has been introduced.
Currently there is a very messy tangle of dependencies between
loaders, machines, sessions, and profiles. Right now the
simplest way to create a test loader instance is to create
a test profile, under which the machine and session instances
will exist.
