Login Page - Create Account

Home >> Support Board

Support Board

Date/Time: Mon, 29 Apr 2024 09:09:52 +0000

How to Post a Message for Support

Post From: Using Visual Studio C++ to create Custom Studies

[2021-12-21 07:42:21]
[Go To First Post]
Bet_More_Tim - Posts: 21
Dude thank you so much! This helps a lot. This is really freakin awesome.

Just to make sure I got this down pat... I posted a picture

I think I get it now for the most part.

Is that first code block part of the study.h file defining the function, or part of the implementation,
as in, possibly, have you fully defined Study::Run() function in the header file, and only provided a prototype for the Study::StartStudy(StudyType StudyType_, SCStudyInterfaceRef sc_) in the header, and then using the Study.lib to implement both(and to only #include study class header files in study.lib), and then in the acsil entry point we only need to #include "study.h" which brings everything it needs?


Another question are the two 'Study*' references.... are those simply existing as class pointers to represent the current study thats being controlled, as in, the studytype returned by the Study::StartStudy() function, such that in the next line we use it where we're checking IsDLLInit and we use 'Study* study'
......I might have figured it out as im typing maybe... This is the persistent instance that exists so things don't keep getting created. and we are either casting the current Study* class pointer to its persistent pointer its been previously assigned (if the chart is not empty and has data)... or were leaving it null until the next step where we then create a new persistent pointer. So that on the first run through we set a newly loaded study equal to a persistent pointer, at which point SetReferences() will get ran, along with Run() which will only initialize things before going back to the top of the StartStudy() function, at which point this time the bool will be false, we don't need to create a new instance of the study class object, and we simply need to cast the pointer to what it was and get on with life.

I guess what I'm not entirely sure of there is, regardless of which study entryway was triggered, its running thru the startstudy function, and getting assigned the same persistent pointer, just to be ran one time, and then every single time the function gets called its re-creating that persistent pointer? I guess this question stems in my lack of knowing exactly how sierrachart calls the "SCSFExport scsf_name(SCStudyInterfaceRef sc_) " function, because if its being called "non stop" in order to calculate a study, thats a lot... however if upon adding it to a chart, it runs that function once, which basically "now it exists and is running", that would coincide with basically "living" in our Study::Run() most of the time, and then when the chart is closed or study deleted, delete the memory.
And along with that, since we can have multiple studies in a dll, will every addition of a study from that dll to a chart then be creating its own instance of being controlled by the study controller, or are all the studies that are in the same dll, while attached to a chart somewhere "fighting for"/"waiting in line" to get used by the controller? I'd imagine these are separate instances since it's entirely conceivable to have the same several studies on several different charts. I suppose this question stems from my lack of knowledge of how sierrachart deals with threading processes?, and whether that would lead to 'bumping elbows' with shared controllers. As if the resources are separately assigned based on the actual instance. (not going to lie I dont even know if this line of questioning even makes sense, but gotta sound stupid to learn i guess lol)


Another thing is in these two lines 'study->SetReferences(&sc_);' and 'study->Run();'... i get the study->SetReferences(&sc); being that the class that 'study' is pointing to is the class where SetReferences lives, but what I'm not sure about is also having 'study->Run(); ... is this because there exists an 'object' or 'class' reference inside the study::Run() function and we want the class object we're pointing to to be the one "used" during?


Edit: I might have figured this last bit out actually.... it's because our study class constructor is a delegating constructor which passes is responsibilities off to the Study() class, and thats why we need to point to the Study::Run() with the class pointer we assigned to the proper study class, such as:
DialogForm::DialogForm(SCStudyInterfaceRef sc) : Study(&sc) {}
where an object created by DialogForm() has its responsibilities delegated to Study(), and we're giving Study the reference pointer to use for SCStudyInterfaceRef class



Is the study controller class lib is going to be where we #include all of our study classes, since the controller is interacting with the models... and then in the acsil entryway, we only need to #include our header file for the controller class along with the #pragma comment(lib, "comctl32.lib") line, which will automatically create the links needed to the static libraries used?


Then from there, the big difference between static and dynamic library linking, is going to be:
-static link brings the library into the dll being compiled, and its all there (as in our acsil dll to sc/data folder)
-dynamic link means we also need to place all linked .dlls in the sc/data folder, but other than that (and some preprocessor directives for exporting functions) we'd be able to implement dynamic libs the same as static libs?



Besides this being a way cleaner method of developing in sierra, the main reason I need to learn to implement things this way is so I can have the functionality of tensorflow c++, and load trained models into a study.

I've also been thinking through what else is actually possible, since it would seem that "everything" is. To that regard I've been thinking through an "on the fly" implementation of a random forest decision tree, or ada/xg boost, to basically load up a chart, have classes that build features, and then splice the sc.Index into train/val, and do it real quick (since these models can train relatively quickly usually), and then auto-reload the chart with the trained model now making predictions in real time (or rather, onbarclose so the "full" feature data is being sent thru the model. And even be able to create a condition such that if the model starts getting too 'off' by some metric for long enough, then it auto splices our sc.Index and retrain/vals and implements the newly trained/updated model.

Similarly, I'm also wanting to implement tensorflow sts models this way, as I'm assuming it should be just as possible as everything else... to have a model structure thats been tested in an external environment, code that sts model into a tf c++ version, and then use recent data in the chart to build prior distributions, and 'every so often' implement MCMC to 'forecast ahead' a few more periods... or rather, really based on the amount of time it takes for MCMC to be implemented, 'on each new bar' run the updated priors to forecast out several bars forward and plot something like E[mid] and ~90% $range confidence intervals.

Again thank you so much for your patience and tolerating my long winded questions lol. I kind of assume I'm asking dumb things due to c++ being "as needed" and not my "daily driver", but I also hugely assume lots of other folks will at some point be searching for similar answers.
Date Time Of Last Edit: 2021-12-21 10:21:10
imagec++ dev.png / V - Attached On 2021-12-21 07:13:14 UTC - Size: 431.21 KB - 398 views