implemented as multi-class assembly DLL's.
Now, I fully realize that you simply can't help the "custom developers"
in every aspect of their work; as NinjaTrader is so flexilble and
extensible. That makes the support effort unbounded and so I
completely sympathize. However...
From what I see, the re-activation of an Indicator, Strategy, or similar
within the NinjaTrader 8 system depends *entirely* upon successful
serialization and deserialization. If this is unsuccessful, then manual
re-activation of the facility is required *every time* NinjaTrader is
restarted.
First of all, is this correct? I think it is... So I am proposing that there
be *an alternative* method for complex assembly DLL's which
*does not depend upon serialization*.
That an Indicator, Strategy, etc. be able to specify reactivation
through a mechanism which is not serialization/deserialization.
Is there already such a facility? and, if not, then I propose that
you consider providing one.
I'm not trying to be irritating here, since I'm so impressed by the
platform; but one of the biggest stumbling blocks is the seeming
inability to satisfy the re-activation requirements through
the serialization mechanisms; and especially on update of
an assembly DLL, even though the same parameter interface
may be maintained, the inability for NinjaTrader 8 to correctly
activate it; thus requiring a manual intervention for activation
each time the platform is restarted.
So I'm just respectfully requesting that some alternative
mechanism be provided so that assembly DLL's with
arbitrary internal complexity; be able to be modified
in implementation, but activated through a mechanism
which does not depend upon the current serialization
constraints
Even a workaround at this point would be helpful; for
example, maybe a "stub" high level NinjaScript generated
object (which would be reliably serialized/deserialized)
could then internally "dynamically load" the underlying DLL
assembly. Maybe that would bypass my difficulties, and
provide a path for DLL assembly activation that might
resolve the issues? At this point, any such workaround would
be welcome ! Any solution would be welcomed. Thanks in advance...
[edit] Like if the "serializable stub loader" would dynamically allocate the
DLL and use its entry points as a "delegate" implementation.
I have a feeling that could work somehow...
hyperscalper
Comment