Ok, I am starting a new thread for my Qt 4 based (http://www.trolltech.com/products/qt/index.html) chart project. The old thread was becoming a bit cluttered with extra-wide code fragments as well as unnecessarily redundant progress screenshots. Ultimately, the software will not just be for charting, but to integrate trading in a way specific to my personality as well. This actually is the main motivation behind the project. I have added the ability to 'dock' or 'undock' a given chart from the Main Window. I understand that many users like being able to have their charts float freely from the main window - possibly for an odd multi-monitor configuration (i.e. 1024x768 + 1280x1024). eSignal does this, Ensign does not. However, I do not think there is a way to add a widget to the titlebar as eSignal does - at least using Qt methods. It would be nice to have a little button next to the 'minimize' button that docks or undocks the chart. I added Global Chart Properties - for now there are (12) color settings only. I will try to add templates so users can have fancy custom color groups. Crosshairs have a transparency slider - right now it modifies the 'alpha' component of the crosshairs color from 0 to 255, I might limit the lower bound to, say, 63. (0 is totally blank and is therefore pretty much useless). The properties will eventually include (no specific order): Splitter Width (right now 2 pixels) Crosshairs toggle Crosshairs type (full, small) Right pixel spacing (between price area and edge of last bar/candle) (0-30?) Bar/Candle/Line default Volume toggle default Default spacing (0-99?) Default font Grid type - dot, solid line, dashed line Grid toggle Date turn grid toggle Session open/close grid toggle Probably more. I have explored the possibility of using a custom frameless window, and adding widgets for minimize/maximize(restore)/close. This would make it easy to add a fourth widget for the 'dock/undock from MainWindow' methods, but I was playing with it and it's a pain. What happens when the window is Maximized? The titlebar has to be shown again, unless the maximize routine is customized to fill the screen manually. Additionally, minimizing must have the titlebar so the user can see the minimized window either on the bottom left corner of the desktop (undocked) or on the bottom left corner of the main window (docked). This would be a really cool feature though, as it would allow custom utilization of space of the top area where the titlebar normally is located. Additionally, the width of the frame could be customized, in a variable style. This one is on the backburner, however, due to the complications involved, and the fact that other issues are far more important at this point (such as consideration of network interfacing, symbol management, proper combination of real-time data with historical data/backfill). I have a nice collection of files from CME's ftp server. The format of the files makes it very easy to split each ASCII line up and create a trade-by-trade custom binary useful for creating literally any type of dataset. The chart types available will be: minute (0-720? Not sure why anyone needs more than 720 minute [1/2 of a day] charts), daily, weekly, monthly, yearly, tick, volume, range?(I don't use range charts but the formula seems simple). I wonder if 'second' charts are useful - I do not use them. But, it is feasible to use the CME files (and/or a real-time data feed) to create, for example, 15 second data. Currently, I use tick and volume charts without synchronizing to the session open - it would be nice to at least make this a user-option. By synchronizing to the session open, consistency of the dataset is ensured - otherwise the whole dataset will be offset variably dependent on the first available data, and whether the source dataset is actually complete/accurate. I don't have the full historical tick dataset for CME products, so having this feature at least available seems preferable. I have already worked out the formulae for calculating tick and volume charts - it's not that difficult - just have to incorporate the synchronization, and consider the best way to handle data across multiple files.. right now I import the CME data so that each session is stored in a separate file, splitting the contracts up. There are actually some fields that CME uses that I am a bit confused about - maybe I'll ask when the time is right. Most is self-explanatory. Moving on, right now I am brainstorming the best way to convert a given time-based dataset to a higher dataset. I have updated the ASCII import wizard to compensate for timezone discrepancies as well as 'late bar' data (i.e. the dataset represents the data from 9:30.00 to 9:30.999 as 9:31 - I prefer 'early bar' and this is what the program will use). The timezone adjustment merely moves all data to 'local' time - 'local time' will be a global setting or possibly simply read from the local clock. I think the global setting is preferable so as to maintain consistency should the computer's clock be inadvertently changed temporarily. This does beg the question - what if the user moves from Florida to Arizona and their data is off by a few hours? Anyway, I digress - that is not too terribly important as of yet. The time adjustment was done as follows - convert the YYYY,MM,DD,HR,MIN variables to a QDateTime, then use that variable to make the adjustment, then convert back to YYYY,MM,DD,HR,MIN. The reason is that when the data is used in the chart, I prefer to use the individual variables for performance reasons. The only overhead is that which I have coded specific to the charting component - i.e. in the date and time algorithms. I would rather have a slight performance hit during ASCII conversion (while making my life easier using Qt's very convenient QDateTime type), but keep performance snappy while charts are in use. Anyway, back to the issue at hand - let's say I want to convert 1-minute data to 3-minute data, and synchronize with the 9:30 open. I usually just scribble some numbers on a piece of paper to come up with a formula, but for some reason this one has me a bit wrinkled right now. Maybe it's still early in the day, but it should be easy. I suspect that using QDateTime will, again, make things a bit easier for this conversion, particularly when considering times that cross over midnight due to the (for example) 9:30 synchronization over odd timeframes. Taking the example numbers, 9:30 means 9*60+30 = 570 minutes since midnight. 570/3 = 190. 570%3 = 0. Maybe this has something to do with it. Something like: 12:00 + (570%3) to 12:00+3 + (570%3). I think that's enough to get me started, I'll write some loops using that idea and see if it works. It's probably wrong, but it will get the ball rolling on this issue. That's enough for now.