| paul1307 |
|
Gold User, Member, Platinum User, TeleChart
|
| Registered User |
|
|
|
|
| Unsure |
|
| Thursday, October 7, 2004 |
| Wednesday, July 31, 2019 4:21:22 PM |
41
[0.01% of all post / 0.01 posts per day] |
|
|
When clicking on TC2000 v18, pop-up screen immediately comes up indicating connection to Worden, and then the program simply fails to load. Any ideas?
|
Very good points jas0501 and a nice synopsis of what I was saying.
In case anyone has not heard, Worden is beta testing a 2011 version of TeleChart which will, presumably, ship in 2011. I have been using it for some time, and find that the charts are quite similar to TC 2007 - though not an exact match - and very easy on the eye and easy to adjust to after having used TC for as long as I have. There are still aspects of the product being developed, but it looks like it will be a nice upgrade from TC 2007. On the downside, however, and I'll assume that this may be one of those items still in discussion and development, EasyScans are as abysmally slow as they are in StockFinder. I suspect they're either using the SF database rather than having abandoned the TC database model.
As a developer, the problem with the TC database is that having been developed under the COM spec way back in the mid to late 90's, it's incompatible with 64-bit application development, and it's necessary to change ones development environment from "any processor" to the alternative (whatever that's called) or you'll never connect to the database. The worrying aspect for me is that if TC2011 continues on the way it is going, developers won't be able to access TC2011 data, and - so far - the limitations of PCF creation in TC2007 are inherent also in TC2011, meaning no looping, variables, conditionals, etc. This will hopefully change as the product continues in development, that is we'll either get more functionality in TC2001 PCFs - or we won't, and in-depth exploitation of the available data will have to be done in SF.
That would be fine, as far as it goes, but i've found through my own experiences that it's generally necessary for me to develop indicators as "classes" within SF, and this has been frustratingly problematic either because my code sucks, my understanding of the interface is faulty, or there are underlying bugs at the conceptual level within SF (it's that whole "Blocks" underpinning that i've never been comfortable with and I suspect that adherence to Blocks has percolated up into the rest of the program in a tail-wagging-the-dog way that causes many of the problems) - take your pick, but know that I'm a reasonably accomplished C# programmer and first started programming BASIC in 1979, had a nice career as a digital-design engineer, and have been around the block a few times. Not to say that I'm infallible by any means, only that some things were less than intuitive and I found myself creating work-arounds, like zeroing out my array elements to prevent errors, something that the compiler should do automatically. Add to that the problem with having to plot only one line at a time on a chart (how does one do dual-plots like MACD when the code won't accomodate more than one plot statement per?), and basically I stopped writing for SF and am developing my own complete program so that I can create indicators, scanning algorithms and eventually a robust back-tester. Currently, tedious as it may be, that seems to be my only option within the confines of the Worden products. Unfortunately "customer service" in the way of responses to questions about SF programming seem to have dried up entirely, so no help from that department.
I really like TC2007. It's extremely fast at processing EasyScans simply because all the PCF values are calculated in advance and stored in the Worden "database." Not so, apparently with SF where they appear to be being calculated on the fly - and much slower. Hopefully TC2011 will return to the TC2007 model before development is finished. TC2007 of course, has severe shortcomings in PCFs but that's probably precisely because the PCFs are pre-calculated and values stored, and opening them up to too much programability also means expanding the TC "database" to accomodate them; tough choice for Worden, and at some point, something's gottag give. I'm experimenting with moving everything to a SQL 2008 - lite DB to see how that works out; 2008 now accomodates 10 GB databases whereas 2005 only managed 2 GB, so the added overhead may resolve space problems, though I still haven't resolved the question of "store PCF results or calculate scans (and hence backtesting calculations) on the fly." More than any other single factor, programming (and design work in general) is all about what to compromise on, where, and why. In the meantime, if anyone would like some source code for accessing TC data in C#, drop me an email and I'll forward it to you; perhaps from there some collaboration might be possible. (paul@fostersutton.com)
Paul1307
|
Flash,
Thanks. I understand the part about extending SF5 to work with .Net 4.0. The part I'm unclear about is the ability I might have to exploit data within SF. For example, the SDK for TC allows me to pull data from TC, then write my own routines within my own program (I work in C# mainly), so I get the flexibility of working in C#, and my program will run at its own speed and pace (depending on how good or bad I code). That actually allows me to do all the things you noted.
What I'm not clear about is how any of this would apply to SF. For instance, if I don't have the ability to export prices or volume to my external program (or DLL) I'm still stuck using SF for calculations. Granted, I could generate an email if a stock reaches some criterion, but the calculations to determine that criterion might still have to reside within SF.
Legitimately, the question might be raised, "Well, if all you want to do is export or extract data from Worden, to where you can use your own program to do the things Flash99 mentioned, you can already do that with TC which, btw, comes free with SF, so why would we bother with providing that same capability with SF?" Good question.
I suspect what Kuff is really asking is whether or not we would like to be able to use (for instance) the .net graphics library, or the system.windows.forms library so we could develop our own user interface, or the system.collections.objectmodel library so we could use dictionary objects, etc. Presumably, if we could use system.linq, we could also export data to a db of our choice; is that what he's offering?
When SF first came out, Worden pointed out that developers could write code and sell it to SF users. I checked with Worden on how a developer could restrict distribution to only authorized purchasers and was told "there is no way." I see now where there is code in the user area within SF for download that requires a password, but that's not real security of the type Worden has for their code. To really produce a marketable product you'd need to replace SF (or TC) with your own program and distribution and authentication system.
Interesting disucssion though, and I'm looking forward to Kuff's comments on the subject to see if it clears anything up. Judging by how slowly responses are coming from Worden/Kuff/et al, to posts in these forums though, I'm assuming that they're either snowed with SF updates, or ...
Keep your stops tight, and good trading,
Paul
|
I do most of my developing using the 'Class' tab and manually stepping through the price series. If the indicator uses 10 prices to calculate my indicator and I scroll the price chart backwards to include the first 10 prices in the plot, the whole chart seems to get squeezed up into the top of the screen. Once those first 10 prices are off the screen to the left, the chart plots correctly.
I'm using MyBase.AddToOutput(datev, value) for the plots.
I've tried not plotting at all for the first 'n' values, plotting the close for the specific date, 'single.nan' (which blanked the whole window!), and I've run out of ideas.
I noticed this doesn't happen when you're plotting something like a moving average that simply "picks up" at the 'n + 1' value, correctly plotting the first 'n' prices; obviously, I'm doing something wrong.
Any suggestions? Thanks in advance.
Also, if I put a "break' statement into my code to debug it in Visual Studio, it seems that almost always, I can lock SF up completely, even when my code runs correctly (excepting what I've noted above) in SF. Any suggestions as to what I'm doing wrong there as well?
Thanks again.
|
|
I'm not sure what's being (potentially) offered; would this open up SF in the manner that the TC SDK did, that is, access to the underlying data, or just allow programmer to use the entire .NET namespace within code developed for custom indicators? I'd assume that SF data would remain 'read-only,' negating concerns that maliscious code could mangle SF or its underlying data.
|
In spite of what the new Programmer's Reference states on page 48, debugging with Visual Studio 2008 does not always work correctly; the good news is that Visual Studio 2005 seems to work correctly all the time ( so far...).
If your code is running correctly, VS 2008 seems to work most of the time, but it jumps off into never-never land eventually and it becomes necessary to stop debugging (since there's no clear indication of what line of your code is executing, if any) from within VS to clear the problem. I would recommend sticking with VS 2005 as a debugger until this gets fixed.
|
Are you using VS 2010 for development, and can we utilize the support it provides for developing code to take advantage of multiple processors or multiple processor cores? It would seem to be a given if SF is being developed under VS 2010...
Not to mention that it would be a great and simple way of speeding up the processing of user-developed custom indicators and conditions in RealCode and, off-loading some of the processor loading on core SF operations and processes.
Paul
|
If you'd like to join me in the Trading Technicals club, I can pass you some interesting PCFs and some additional information. We primarily use a voice chat system that is explained on the club home page. We've been working on some interesting ways of tracking stocks and you might be interested. We don't monitor the chat too much, so a PM would be the best way to get my attention.
Regards,
Paul
|
|