Home >> Support Board

Support Board

Date/Time: Tue, 23 Apr 2024 06:51:03 +0000

How to Post a Message for Support

32-bit Builds of Sierra Chart to be Discontinued with Newer Versions

View Count: 9789

[2019-12-31 13:06:43] #50 [Go To First Post]
WarEagle - Posts: 70
Do you have the source code for this? Yes I have the code. I am attempting to rebuild it in VS 2019. I was able to build a generic 64 bit dll that runs in Sierra so I think I have the main settings correct now. When I #include the external functions they show up in the intellesense information but I get the same errors as the VC++ build through Sierra gives me (unresolved external symbols). All the code is there so its probably something I am doing wrong linking it all together. I will keep working on it but thanks for allowing a 32 bit version to be available for now. EDIT: I think I figured it out, just needed to place the correct source files in the right place. The problem of being a trader and not a programmer. Thanks for a great product that I can even do this with. Date Time Of Last Edit: 2019-12-31 13:29:34

[2019-12-31 16:19:23] #51 [Go To First Post]
Sierra Chart Engineering - Posts: 104368
We have added MESA Adaptive Moving Average into the main list of studies now. In regards to post #50, if you have the source code you will need to compile those functions as a 64-bit DLL or static library. It sounds like you have the linking problem resolved. Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, change to the Teton service: Sierra Chart Teton Futures Order Routing Date Time Of Last Edit: 2019-12-31 16:19:39

[2020-01-01 00:14:49] #52 [Go To First Post]
FFTrader - Posts: 180
We have added MESA Adaptive Moving Average into the main list of studies now. Is it coming in the next version? I have version 2028 / 2031 as do not see "MESA Adaptive Moving Average" listed.

[2020-01-01 00:52:19] #53 [Go To First Post]
Sierra Chart Engineering - Posts: 104368
Yes. Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, change to the Teton service: Sierra Chart Teton Futures Order Routing

[2020-01-04 15:58:26] #54 [Go To First Post]
FFTrader - Posts: 180
Regarding "MESA Adaptive Moving Average" A reference just in case - with source code files, etc. MESA Adaptive Moving Average

[2020-01-21 12:19:44] #55 [Go To First Post]
Matt654 - Posts: 73
I use the special formulas and real time charts in Excel which I've created over the years, so just so you know I'll be looking for other software that uses Excel, once you terminate its use. Excel is one of the main planks to my trading system.Have you got a fixed date yet for when you intend to stop using it.

[2020-01-21 20:40:23] #56 [Go To First Post]
opci - Posts: 90
post 14@ All the questions relating to 32-bit versus 64-bit will be eliminated. We definitely are only going to be supporting the 64-bit version. And probably sooner rather than later. i have a simple question, which version latest supports 32 bit custom dll?

[2020-01-22 09:56:17] #57 [Go To First Post]
Sierra_Chart Engineering - Posts: 14052
The latest version 2037 still supports the 32-bit version of Sierra Chart. I use the special formulas and real time charts in Excel which I've created over the years, so just so you know I'll be looking for other software that uses Excel, once you terminate its use. Excel is one of the main planks to my trading system.Have you got a fixed date yet for when you intend to stop using it. This has already been removed in recent versions of Sierra Chart. But we are going to add a feature to periodically save a Sierra Chart sheet to a text file which can then be automatically read and refreshed in Excel. Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, use the Teton service: Sierra Chart Teton Futures Order Routing

[2020-01-22 10:00:26] #58 [Go To First Post]
Matt654 - Posts: 73
I am only using Excel on the 32 bit not dll, I can get feed for excel at lots of places when the time comes.

[2020-12-20 16:47:31] #59 [Go To First Post]
User791263 - Posts: 151
I watch posts re Change Log to avoid version updates that might cause my large system problems. I've had trouble twice before, finally abandoning a larger version I had converted to 2nd instance (I lost months), but decided reducing size/complexity for speed was needed by me. I have no need for 64-bit micro-second stamps, inside bar tick by tick calcs, or anything past V1991,which works well and fast. Trying to have the most-recent workable 32-bit version, I studied versions and tried V2012, as I saw fixes of V2006 in V2007 and saw your attempt to "improve" recalculation of tagged references in V2003. --> "2003 Release Date: 2019-10-25 New option for text drawings ... When studies in charts make references to other charts, Chartbook loading can be faster because recalculation due to tagging with changes in source charts, only occurs once all chart data is loaded among all charts. ... " That recalculation of tagged charts, "occurs once all chart data is loaded among all charts"-- did not work at all for me: It went into constant recalculation, mostly locking SC. I changed nothing between my fast V1991 and V2012 (I think I tried V2007 too). Same problem. If going forward 16 versions did not work, I shudder to convert my one DLL and still get the constant recalc problem in a 64-bit. Having been a programmer, I sympathize greatly with attempts to "improve" that may fail in unusual cases. Most SC users are perfectly happy with stable, fast 32-bit. We understand your priority to improve data feeds/symbol changes; Those are not our priorities. Our priorities: Refine and finish off our own years of work on a stable, fast platform. Some of the best traders trade trends, not even concerned with seconds. Internet lag is about 50ms makes msec stamping debatable. Better use of DOM is all the "inside the bar" most of us need, such as a couple of money-making simple added tools (such as Max DOM Tracing (similar to fill-coloring between studies by Reference study. ie: shows few-second direction of max DOM bar). But if staying with fast, simple 32-bit without improvements is the choice over tools, we'll stick with stable 32-bit and write our own tool, if you give us Market Depth data layout. Bottom Line: Please, let us stay with 32-bit. Maybe just update 32-bit once a year for data feed/symbol compatibility and add a couple of studies/improvements like Max DOM bar trace. Please; I bet lots of users would agree with me in a user survey. Some of us would just like to become profitable enough to send you a $ bonus, once in a while. Happy Holidays.

[2020-12-20 21:21:23] #60 [Go To First Post]
Sierra Chart Engineering - Posts: 104368
Since the release of Windows 7 (October 22, 2009.), both the Windows operating system and also hardware platforms, and well before that for hardware, have supported 64-bit architecture. 64-bit architecture is very well established for 10+ years now. Our experience, is that Sierra Chart is faster running as 64-bit. That may not be universally true on older hardware platforms, but certainly is on up-to-date hardware. Hardware these days is inexpensive. We are really not understanding the push here to be maintaining 32-bit architecture. We do not know why this would be the case as it does not make technical sense: did not work at all for me: It went into constant recalculation, mostly locking SC. There must be another cause for the issue. It could not have been this: When studies in charts make references to other charts, Chartbook loading can be faster because recalculation due to tagging with changes in source charts, only occurs once all chart data is loaded among all charts. ... " This makes no sense either: I shudder to convert my one DLL and still get the constant recalc problem in a 64-bit. Running in 64-bit mode does not change the behavior of program code. It functions identically. So once again there must be some other cause for the issue you are having. There must be some circular reference going on. We see that you are incorrectly faulting 64-bit architecture as the problem. Would be best that we help you identify what the issue is with these continuous recalculations. In our server environments we have used 64-bit architecture exclusively for many years now. It is absolutely essential to handle the large memory requirements and the load. And everything works exceptionally well. Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, change to the Teton service: Sierra Chart Teton Futures Order Routing Date Time Of Last Edit: 2020-12-20 21:23:46

[2020-12-21 02:32:43] #61 [Go To First Post]
User791263 - Posts: 151
I run Win 7 Pro 64 bit on O/C'd 2500K, 16 Gig; There's no 64-bit fear or memory limits here. I'm not "incorrectly faulting 64-bit architecture", as you accuse. Many of us just don't want or need 64bit SC." I cited only a V2012 problem that will be in later versions. (You usually say your changes "could not cause problems"). No change you make should cause what worked perfectly before to quit[/u]! You are missing my factor of many delicate timing dependencies. me: V2012 32 bit "did not work at all for me: It went into constant recalculation, mostly locking SC." you: "There must be another cause for the issue. It could not have been this: [ <----- ] 'When studies in charts make references to other charts, Chartbook loading can be faster because recalculation due to tagging with changes in source charts, only occurs once all chart data is loaded among all charts. ...' " That change will behave the same in 64bit. You say "There must be some circular reference going on". There are critical tuned update intervals/timing issues as overlays funnel down through 30+ charts. You've not encountered many dependencies like this as a user, so how can you say that is not involved?. After long tuning of update intervals, I can't spend weeks debugging that for no good reason, since no reference affects my results, V1991. V2012 was not giving a "circular reference" message. The change just screwed up delicate timing. I don't need risk and extreme work. I've been through that before. You repeatedly told users during late 2019 and most of 2020 we could "keep using 32 bit". A new datafeed may not be exploited by old versions, but if V1981 - V2002 run with our broker feed, we don't care. Changes must #1) run better, 2) improve profitability. No later features do that better, for me. Able to run "at all" is absolute #1.. so I need V1991-2002. Not all users tell you problems and work that some changes caused. Please do what you told us. Maybe offer an optional datafeed module patch, or A rare new 32b study you say requires no different source code. Maybe charge V1981-V2026 users $10/mo. to support datafeed patches. I'd gladly pay $10 per month to not be forced, again, to upgrade for a couple of years.

[2020-12-21 12:47:46] #62 [Go To First Post]
IconBob - Posts: 61
I know how frustrating change is but it's time to move to supported software i.e. win7 pro to win 10 pro, sierrachart_32 to sierrachart_64.

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