Home >> Support Board

Support Board

Date/Time: Mon, 29 Apr 2024 10:20:47 +0000

How to Post a Message for Support

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

[2021-12-21 11:40:30] Link To Thread - Link To Post [Go To First Post]
User310645 - Posts: 49
Your picture looks good. But just to clarify each study you add to the chart can only control one of the GUI implementations. All this wrapper code is because they all share common code. >>Is that first code block part of the study.h file defining the function, or part of the implementation, Study is the base class so each implementation (Slider, Combo etc) extends this. DoInit(), DoStudy() etc are virtual methods in the Study base class so Study::Run() is calling the actual immplentations eg. Slider::DoInit(). ie. Its just polymorphism. We store the Study* so don't care what the actual implementation type is. Study::StartStudy is static factory method to create/retrive/run the study implementaion when sierra calls in. study.h/.cpp will pull in the .h files for each of the study type implementations. >>Another question are the two 'Study' references.... We are simply creating the Study if none already exists and cannot be retrieved from sierra sc.GetPersistantPointer(). Otherwise you would need to recreate these each time sierra calls in (which for a GUI object is obviously not what you want). Sierra studies are normally stateless. Each chart update calls into SCSFExport function and you normally perform whatever calculation you have at the current index. The wrapper just serves to make it more C++ like and keep a persistant object rather than recreating it each time. >>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, Again this is just down to sharing code. Although they all call the same code, as far as Sierra is concenerned there are 4 SCFExport entries which means 4 different studies. >>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... yes its called a lot - whenever data changes (within the bounds of its update cycle) >>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, Yes each time you add a study to the chart they get their own instance. However, you need to be mindful of any shared memory within the DLL. eg. static variables that only have one copy within the DLL >>how sierrachart deals with threading processes? For updating charts Sierra is single threaded so each study gets one call on each chart update cycle >>Another thing is in these two lines 'study->SetReferences(&sc_);' and 'study->Run();'. see above >>we'd be able to implement dynamic libs the same as static libs? yes, its a similar method but if you are not sharing the code beyond a single study you might as well just compile it all togther. ie. a single visual studio solution containing a dll project and all the individual source header files. If you are talking about external DLLs where you don't have the .lib then you will need load it at runtime and call the exported methods via LoadLibrary() and GetProcAddress(). >>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 yes you can link in any external library in the same way as if you were creating a stand alone application I've never used tensorflow but I would imagine you would need to keep the tensor flow "model" as a static/persistant varaible in much the same way as the UI components above as you probably don't want to be creating it every call (although maybe you can, in which case a lot of this is unnecessary :-)) On each call into the study then test your model with the updated data. Extract the result from the model and plot into a subgraph. Feel free to PM me as this is getting off topic from the OP. Cheers