Split camera device base class into Base and LegacyBase#590
Split camera device base class into Base and LegacyBase#590marktsuchida merged 8 commits intomicro-manager:mainfrom
Conversation
marktsuchida
left a comment
marktsuchida
left a comment
There was a problem hiding this comment.
Thanks for doing this as a separate PR. I'm okay with immediately renaming to "legacy" -- makes sense if going ahead with modifying the camera adapters.
|
It says you requested a change, but for some reason I don's see what that is. Is there anything else needed before merging this? |
I think you made the 'small fixes' commit at the same time I was reviewing. In it, you fixed But now that Also, I commented that the (See my comments above that are marked resolved.) |
Probably. This was a simple refactor-rename, so I think that can be done in a separate step (#598)
Fixed in previous commit |
Should be all addressed now |
|
Thanks for the fixes.
I'd rather rebase this PR so that it never touches the cameras that it doesn't need to touch, but I can do that when merging this (which should be soon). |
(Base class constructors are automatically invoked in C++.)
Members of the base class template need `this->` or `using` to compile.
Restore compilation of these cameras without changing behavior. Rather than inheriting from CLegacyCameraBase, simply supply a Busy() that returns false, which is the same behavior as with CLegacyCameraBase::Busy(), given that no other legacy functions are used in these cameras. Left a comment on Multi Camera's Busy(), because theoretically it should forward the physical cameras' Busy() results. However, it is out of scope for this commit to change behavior (and Busy() on cameras traditionally does not get used).
Mostly calls to the base class default constructor. One cast to base class pointer in DECamera.
Made sure that all occurrences of CCameraBase is replaced in these cameras, so that behavior should match previous. Some of these cameras only make minor use of CLegacyCameraBase member functions, and can be made to work with the new CCameraBase with little work, but doing the simplest transformation for now.
These cameras only made simple use of the legacy functions, so switch them back to CCameraBase with the appropriate fixes: - Supply missing StartSequenceAcquisition(double) overload - Supply missing Busy() - Replace calls to OnThreadExiting() with equivalent code (but without the unnecessary try-catch) - Replace calls to setStopOnOverflow()/isStopOnOverflow() with a data member (QCam only)
marktsuchida
force-pushed
the
split_camera_api
branch
from
5bc3055 to
93f7a46
Compare
|
Force-pushed to redo the fixes to device adapters (to avoid touching the ones that don't need to be, to fix cameras that are not built on Windows, and to resolve conflicts). This should be ready to merge now but I'll give it a once-over at a better time of the day before doing so, given that I'm making untested (albeit nearly mechanical) changes to devices :) |
Additional member functions are needed in a mock camera now.
|
Here are the camera adapters that ended up having to use
(16 total) |
2 participants
As discussed in: #243 (comment)
This splits the camera base class that all camera adapters derive from into a legacy class (
CLegacyCameraBase) which derives from a new, preferredCCameraBaseclass. The primary difference between theses is that the Legacy class contains a bunch of code for implementing sequence acquisitions as a series of snaps, which was originally for debugging, but ends up being inherited by all camera devices adapters.I changed the name to LegacyBase now, rather than in the future as described in (#243 (comment)), because it seems like we would already like device adapter writers to inherit from the new base class.
See below for a few questions.