Home >> Support Board

Support Board

Date/Time: Mon, 29 Apr 2024 11:38:08 +0000

How to Post a Message for Support

[User Discussion] - Using Visual Studio C++ to create Custom Studies

View Count: 7518

[2020-11-07 15:56:26] #1 [Go To First Post]
User972768 - Posts: 166
Hello SC users, With very little support from Sierra Team in area of how to use Visual Studio, I felt that something like this thread will be useful for many who wish to embark on this adventure. Visual Studio Community edition is modern Integrated Development Environment (IDE) that allows one to develop and debug any Custom Sierra study with the might of C++. Just to start the conversation, I'm adding list of non-default configuration settings that I use in my Sierra-related projects. Cheers Date Time Of Last Edit: 2020-11-07 15:56:44


VisualStudio_DLL_config_template.txt - Attached On 2020-11-07 15:56:04 UTC - Size: 2.79 KB - 768 views

[2020-11-07 16:06:18] #2 [Go To First Post]
User972768 - Posts: 166
And here are some of my tricks that I use: 1) If you build something more complicated than Moving Average line, don't use "Remote build". I highly recommend to use Visual Studio (VS). I have Visual Studio C++ 2019 Community Edition (which is absolutely free for single developers, it lacks some team-related functions as a result, but that's fine). My VS 2019 is configured to use C++17. 2) I recommend you to use full power of C++ language and package actual study calculations into C++ class(es). Use ACSIL mostly to manage your class and let Sierra present results of calculations. This is perfect example of MVC model (model-view-controller) where your class(es) is/are the "Model", ACSIL is the "Controller" and Sierra is the "View". With this approach my studies have just 3 functions / procedures: - entry point (scsf_) - procedure to set defaults (the one called at sc.Defaults) - (optional) dynamic memory manager where I allocate / release memory for my class objects You might still have a question why do I do it this way, while Sierra support folks say tons of negative words about Visual Studio, its complicated way of doing things, etc. First, Sierra folks admit to use Visual Studio themselves. I agree with them that configuration of this monster is a bit complicated comparing to GNU text-file based environment for make and ld. But after you configure VS, you rarely come back to this area of the interface. Second, VS nicely integrates with Git (I recommend to use "Git Extensions" as VS Addon and as a standalone app). These 2 pieces of software allow you to use full functionality of Git with many functions available right from VS menu. Start Git repository as soon as you get first iteration of your study working. Start Git repo from VS, this way it will be properly configured to track changes in your code as well as configuration of the solution / projects. Why Git is important in any software development deserves separate thread, but in just few words: "you really really really have to use it" Third, Using "Remote compilation" through Sierra interface has a lot of disadvantages versus VS. To name few: - remote method statically links a lot of libraries (eg, STL) and makes you DLL huge while you might have just 100 lines of code in your study - you can't debug your code like in VS IDE interface with step-by-step, conditional breakpoints, etc - it is very painful to remote compile your study if its source code is divided into multiple files (.h, .cpp, etc) - you can't add functionality of extra libraries (eg, boost, zlib, etc) Fourth, If you detach your core calculations into classes, then you can write unit tests (eg, C++ Google Tests). This brings HUGE benefits and time saving in your development: - with test cases you can create specific data sets to test your code against, and then it takes less than a minute to run tests against dozens if not hundreds of test cases and see if new change in code breaks something that you didn't guess before. Or if you know that new change will break something, but you don't know extent of this breakage. In few words, you will see EXACT effect of the change and weed out all unexpected places much quicker - running test cases doesn't involve Sierra application and its dreaded cycle of "Release library - Compile - Allow DLL load - Test". Yep, you can say here that there is UDP call to do it more automatically, but it is still a big pain in the neck and still is VERY time consuming - you will never beat quality and time of automated tests by doing manual testing by opening specific moments in the charts that cover some test cases - if you come across some new edge case(s) where your study produces incorrect results, you just create new unit test; make sure that it fails with current code; fix code; make sure that you unit test is succeeding now - rule of thumb says that unit tests usually have 1.5 - 3.0 times of lines of code comparing to what they test (eg, 100 lines of code of your class might have 300 lines of tests to have good coverage of basic functionality and all edge cases). There is even a modern paradigm: "test-driven development", where you develop unit test and then build code that will produce expected results Fifth, Last but not least. Using Visual Studio, you can nicely split your code into many manageable files. In my example, I've build multiple Sierra Custom Studies libraries and some of them have more than 6000 lines of code. Instead of scrolling through huge multi-thousand line long single file, I have many files with biggest of them no longer than 300 lines. Each of my studies live in their own file. They have headers in separate files. Each class is in its own file. Each unit test follows the same structure. Please be warned, that it might be a bit painful to setup Visual Studio to produce Sierra Custom Studies, but the time spent doing it will well worth it. In the end you will get very nice environment. Date Time Of Last Edit: 2020-11-07 22:02:56*

[2020-11-08 00:54:33] #3 [Go To First Post]
User701453 - Posts: 176
All this headache and frustration can be avoided if SC would simply create its own development environment along with the ability for strat optimization. Date Time Of Last Edit: 2020-11-08 01:13:08

[2020-11-08 01:12:35] #4 [Go To First Post]
User701453 - Posts: 176
@User972768 It seems you are an Advanced superuser of VS. Would you happen to have a VS/ACSIL template or project that creates a windows form.? That can be coded into an SC strat or indicator then will display and interact with a SC strat or indicator (ie change value of input variables)the strat or indicator would check the form variables and override any static input variables that was set from the SC inputs.

[2020-11-12 15:56:46] #5 [Go To First Post]
Tonkadad - Posts: 235
Anybody interested in creating a new trade window?

[2020-11-26 22:59:20] #6 [Go To First Post]
Ticks - Posts: 174
I dont think anyone has figured out how to create any kind of window form with SC. SC techs haven't been able to provide any sample code even tho lot of customers has asked for the ability.

[2020-11-27 17:54:16] #7 [Go To First Post]
User310645 - Posts: 49
Its sierrachart you can do anything! You have access to any API so just include it and link to it. Using Win32 API GDI you can call CreateWindow to create windows and common controls. The attached shows a custom power meter rendered directly to a study and also in its own window.


sc-window.PNG / V - Attached On 2020-11-27 17:54:07 UTC - Size: 19.51 KB - 732 views

[2020-11-27 23:26:36] #8 [Go To First Post]
Ticks - Posts: 174
Excellent. Could you share an example .cpp file to create the form and controls???

[2020-11-28 12:18:42] #9 [Go To First Post]
User372626 - Posts: 59
Excellent！ Could you share an example .cpp file to create the form and controls?

[2020-11-30 10:56:20] #10 [Go To First Post]
User310645 - Posts: 49
I have a framework I use to start studys that have GUI controls which basically handles the SC lifecycle functions (Init, SetDefaults, CleanUp) for each study. I'm not going to post all of that as I don't want to distract from the matter in hand which is just creating the UI components. The Study is also responsible for creating the study and storing it in a sc.SetPeristentPointer as we don't want to recreate the components on each run and destroying everything when done (sc.LastCallToFunction). I see 3 main ways to create GUI components: 1) Use the SC callback sc.GDIFunction which is basically a hook into the main forms WM_PAINT event that allows you to draw your own GDI graphics directly onto the study This is how the example posted worked with the power meter simply being ::GradientFill() rects rendered to the HWND of the study and new window. 2) Use common controls (EditBoxes, Combo, Buttons etc) which can be drawn directly onto the study As the controls are using the parent windows WNDPROC for message processing you will need to implement subclasses to handle any events the control might generate. You will need to link to comctl32.lib/#pragma comment(lib,"commctl32.lib") and call ::InitCommonControls() somewhere in the Init() of the study. 3) Create a new window and handle your own messages For most cases you could probably get away with creating a blank study with all scales/scrollbars/draw types removed and use a combination of 1) and 2). This way is likely to yield better results as the window will play nicely with the SC infrastructue. If you really want to create your own window bear in mind you will need to handle all the windows message pump events yourself and will be on your own outside of SC. It must be noted that there is nothing special about 2) and 3) in relation to SC. These are just standard API calls that you would perform in any windows app using GDI. I've attached a couple of stripped down files that hopefully will help. DialogForm.cpp shows an implementation of my Study class which just sets up a simple dialog with 2 text boxes (that have attached labels) and a button. On clicking the button the value of an input parameter on another chart is updated to the contents of the first text box. Button.cpp shows a simple wrapper of the GDI object and applying the subclass for the click handler. The state is checked on each execution in Study::DoStudy() method. WindowFactory.cpp (part of Button.cpp) shows a cutdown version of the factory that creates GDI objects. The idea here was to abstract away the underlying technology so could use another graphics frameworks apart from GDI. HTH


dialog.PNG / V - Attached On 2020-11-30 10:54:55 UTC - Size: 12.9 KB - 627 views DialogForm.cpp - Attached On 2020-11-30 10:55:02 UTC - Size: 2.07 KB - 593 views Button.cpp - Attached On 2020-11-30 10:55:57 UTC - Size: 3 KB - 428 views

[2020-12-18 11:19:02] #11 [Go To First Post]
User462086 - Posts: 188
This is great! Will the samples in post #10 work with OpenGL turned on? Drawing with GDI using SC's 'DrawToChart' does not. I'd like to make a separate window with 2 list boxes and a couple of buttons.

[2020-12-18 12:05:03] #12 [Go To First Post]
User310645 - Posts: 49
Yes you should still be able to use the common controls in OpenGL.

[2021-06-29 19:04:29] #13 [Go To First Post]
User30743 - Posts: 364
hello, can anyone give me hint on how to set things up so that i dont need to detach the study (or close siera) everytime I make a change in the code? i use visual studio 19 community. Date Time Of Last Edit: 2021-06-29 19:05:17

[2021-06-29 19:36:34] #14 [Go To First Post]
bradh - Posts: 854
If you are not making changes to the Settings or Subgraphs, then you can close the chartbook, build, and re-open the chartbook.

[2021-06-30 08:01:17] #15 [Go To First Post]
User30743 - Posts: 364
If you are not making changes to the Settings or Subgraphs, then you can close the chartbook, build, and re-open the chartbook. well, that is exactly what I don't want to do, every time close/open chartbook or detach/attach study etc.. isn't there any (easy) way to set things up for development with visual studio 19? with remote build, there is no need to detach or close anything. just rebuild and the changes are immediately reflected Date Time Of Last Edit: 2021-06-30 08:02:31

[2021-06-30 11:24:16] #16 [Go To First Post]
bradh - Posts: 854
User30743 says: well, that is exactly what I don't want to do, every time close/open chartbook or detach/attach study etc.. IF you do not change the settings or subgraphs, (i.e. anything in sc.SetDefaults) then you don't have to close the chartbook or detch/attach the study. Just do a Chart>>Reload and Recalculate (Insert Key) after the rebuild. If you do Analysis>>Build With Visual C++ Release (Or Analysis>>Build With Visual C++ Debug) it works the same as Remote build as far as closing the chart goes. with remote build, there is no need to detach or close anything. just rebuild and the changes are immediately reflected Not if you change the sc.SetDefaults block. Then you will find the change wasn't captured with remote build. Date Time Of Last Edit: 2021-06-30 11:24:41

[2021-06-30 15:43:02] #17 [Go To First Post]
jmt816 - Posts: 45
User30743 well, that is exactly what I don't want to do, every time close/open chartbook or detach/attach study etc. At the risk of stating the obvious (tho it might be what you are missing), when you go to rebuild your DLL, are you first going to Analysis--> Build Advanced Custom Studies DLL and then from the Build menu, select either "Release All DLLs" or "Release Single DLL"? As bradh already mentioned, if you are not changing anything that impacts on defaults (plus adding/removing inputs, add/remove subgraphs, etc.), then there would be no need to close chartbook, remove study, etc.

[2021-06-30 16:46:25] #18 [Go To First Post]
User30743 - Posts: 364
sure i got it, it seems like it works. yet, I would prefer to have an automated solution so that I don't even need to click Release and then click Add. just clicking build in Visual Studio and all the Release/Add stuff would happen behind the scene Date Time Of Last Edit: 2021-06-30 16:47:20

[2021-06-30 17:00:24] #19 [Go To First Post]
bradh - Posts: 854
jmt816 says: At the risk of stating the obvious (tho it might be what you are missing), when you go to rebuild your DLL, are you first going to Analysis--> Build Advanced Custom Studies DLL and then from the Build menu, select either "Release All DLLs" or "Release Single DLL"? It is not that obvious, but the answer is NO. There is no need to release DLLs when you use any of the build options on the build menu: Remote, Visual C++ - Release, and Visual C++ - Debug. The build menu takes care of the release and reload of DLLs, and you can confirm this in the Message Log: Disallowing loading of DLL: C:\SierraChart\Data\My_Custom_Study.dll \| 2021-06-30 11:47:31.820 Setting study DLL module function objects to indicate DLL is not loaded: C:\SierraChart\Data\My_Custom_Study.dll \| 2021-06-30 11:47:31.820 Unloaded DLL: C:\SierraChart\Data\My_Custom_Study.dll. Handle: 7ffe84730000 \| 2021-06-30 11:47:31.821 I do all my builds this way, never in Visual Studio, which really simplifies the configuration of VS. I am probably missing out on some of the advanced features of VS, but as long as I can edit, use Git, and debug with VS, I am OK. Date Time Of Last Edit: 2021-06-30 17:02:37

[2021-12-03 21:26:59] #20 [Go To First Post]
KylieV1618 - Posts: 59
my question is. I cant even build anything. I dont know how to build a file. I load a file into Visual Studio.cpp and the Build menu just says "Run Code Analysis on Solution", and clicking it does nothing. And when I try to buil through sierra chart with Build With Visual C++ Release then it says it cant find any of the files required. Even though I clearly have Visual Studio 2019 installed and working. (although I guess Building doesnt work??) I have VisualCCompile.bat downloaded and in the ACS_Source folder. The other erros say it cant find vcvarsall.bat. (Visual studio 14? which I dont have) And then all this other crap about environment variables, none of which it can find. NDEBUG USRDLL_d Zc.inline etc etc etc Date Time Of Last Edit: 2021-12-03 21:29:13

[2021-12-05 05:01:53] #21 [Go To First Post]
ondafringe - Posts: 248
@KylieV1618 Try moving your cpp file to the SierraChart>ACS_Source folder and then use SC>Analysis to locate the file and build form there. Date Time Of Last Edit: 2021-12-05 05:04:04

[2021-12-14 20:04:48] #22 [Go To First Post]
WarEagle - Posts: 70
First of all, thank you User972768 for creating this thread. It is nice to see there are other users that need VS capabilities. Back when Sierra supported VS implementation I used it to create some custom work and have felt on my own ever since. I have run into a problem that maybe you or someone else on this thread might know the answer to. It is no doubt a result of my being a trader and not a programmer. All of my programming is self-taught out of necessity and so as you can imagine it is likely lacking in proper structure and protocol. In brief, I have a list of indicators I wrote that use something called the Swiss Ephemeris. This is a third party library of functions that calculate astronomical positions, so things like a full moon, eclipses, etc. I was never able to access the dll for this library from code made in Notepad+ and compiled using the Sierra remote build. There may be an easy way to do this but I have never been able to get Sierra's compiler to see an external library. So I turned to VS. It took me over a year to figure out how to get it to work there, ultimately requiring me to add a lot of .c and .h files from the Swiss Ephemeris source code which is already included in the dll they provide. Once all of that was added to my project, the dll I created worked in Sierra. Since then, whenever I needed to add something I just shut down Sierra, build (in debug, the only way it worked) the updated dll and reopen Sierra. The problem comes in trying to get it to work on another computer. I have a trading friend that I want to share the indicators with. He dropped the dll I made into his Data folder just as it is in mine. He placed the Swiss Ephemeris dll file (along with all its source code) in the ACS_Source folder just as my VS build settings show as the location of dependency files. We have even gone as far as to make a direct copy of my ACS_Source folder to replace his to make sure all the files are the same. No matter what we try he can not see the indicators. In the start up log it shows the dll load, seemingly without error. Other custom dlls that do not rely on the external library load that were remote built in Sierra and they work fine. When a new chart is opened, the log shows all the custom dlls load except for the one I built with VS. I do not know if this is because I have some file in the wrong place or if something is happening on the computer where I build the indicator in VS that allows Sierra to see all the files it needs whereas on a different computer it is missing something. We have tried to replicate everything on my end with everything on his end and nothing seems to work. I worry that if I ever get a new pc I may not be able to get it all working again. Unfortunately the programmers of the Swiss Ephemeris are as equally unhelpful as Sierra since this problem is so unique that neither side has any interest in it and it clearly seems to be from user error. Does this make sense to any of you experienced Visual Studio users? I really appreciate any tips you might have.

[2021-12-14 20:41:51] #23 [Go To First Post]
User972768 - Posts: 166
@WarEagle Thank you for your warm words. I would check simple things first: 1) place your 3rd party DLL into Sierra's Data directory 2) if #1 wouldn't help add path to directory where this DLL is located to your system %PATH% As long as your own code works after compiling in Debug mode, it should also work in the Release mode. Release mode produces much smaller and often much faster DLL. The faster your DLL the faster is Sierra overall. Cheers

[2021-12-14 23:28:59] #24 [Go To First Post]
WarEagle - Posts: 70
Thank you so much User972769, Following your steps: 1) On my pc (where the indicators work) I do not have the dll located here but just to be sure I had him try it on his computer. In the log the only difference was an error message that there was no version number for that dll file. I am guessing Sierra is thinking this is a custom indicator rather than the library for another one so it is trying to open it as such. Since things are working on my end without the file here I am thinking this is not the issue. 2) I looked at my system paths and compared to his. I am attaching a screenshot showing both. We both have Windows/system32 (one of several places where the dll is located as we tried to put it where it might be found by Sierra). The others seem to be application specific. Do you know if there is a way to find out where Sierra is looking for it? It seems to me that #2 is the likely problem since it works fine on my end but not on his, however as best I can tell he has the dll in the same locations that I do.


system paths.png / V - Attached On 2021-12-14 23:16:01 UTC - Size: 985.86 KB - 193 views

[2021-12-15 17:38:08] #25 [Go To First Post]
User99735 - Posts: 234
Sometimes the issue with dll's not being recognized is due to "VC++ redistributable" not being installed on the system. Check out https://docs.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170

To post a message in this thread, you need to log in with your Sierra Chart account: