|
PureBytes Links
Trading Reference Links
|
Tomasz,
is it too much trouble for you to log the Time & Sales data to file as it comes in? This would at least enable us to read that data and construct charts based on the info, as it's not possible to accurately gather this data through chart scripts.
I tried for a while using GetRTData so I could track trades hitting the bid vs ask, but the fact that I can't get this info for every tick makes the data invalid. If Time & Sales was logged (ala eSignals file format for saving replay data), I could then process that file to strip all the data I needed from it.
Regards,
Julian.
--- In amibroker@xxxxxxxxxxxxxxx, Dennis Brown <see3d@xxx> wrote:
>
> Brian,
>
> You asked:
> > ...is there any way to know when a quote (tick) has arrived other
> > than Status("redrawaction")? ... this seems to be a generic trigger
> > so we can't separate new quote from the other possible causes of
> > actioned refresh.
>
> Of course there is. There may be a simpler method, but you could save
> the Time Stamp and Volume of the last bar in a static variable at the
> end of each pass (Time Stamps have to be set to start of bar), then on
> the next pass check to see if the Time Stamp or Volume has changed.
> If they are the same, then the refresh is for some other reason than a
> new quote. Just checking the Time Stamp will indicate a new bar. If
> the bar has not changed, then the Volume is checked for additional
> trades. The OHLC may not be any different even though more trades
> have been made. What you check is based on what you need to know for
> your algorithm.
>
> BR,
> Dennis
>
>
> On Jul 5, 2009, at 7:10 PM, brian_z111 wrote:
>
> >> If you go to the data provider's sites, they tell you exactly what
> >> they provide and archive.
> >
> > Thanks for your summary.
> > You have saved me a lot of research time.
> > In fact your answer is about all of the info I need really (perhaps
> > I will check the detail on my provider eSignal).
> >
> >> BTW: The backtests (on historical intraday data) can show good
> >> >trading performance that is not
> >> duplicated in realtime.
> >
> > Yes, I made a mental note of that point when Herman brought it to
> > our attention earlier on (I missed a lot of the other discussion on
> > RT performance though because I was focused elsewhere).
> >
> >> For very high speed
> >> trading Herman has many more caveats in the UKB.
> >
> > Yes, I can see what he is on about now.
> > He has made a pretty decent contribution to the AB community and
> > even the general trading community.
> > I doubt if there is a better AT training ground anywhere.
> >
> > Of course I will go and read it ... lots of code tends to scare me
> > off but the UKB format is the best support for the code that we have
> > (outside of Howard's books .. go Howard go!)
> >
> >> RequestTimedRefresh ....has two other useful modes that are not
> >> >time based. The 0.1 second refresh minimum time can only be
> >> >achieved when refreshes are triggered by new quotes (ticks) in the
> >> >data stream at a rate equal or less than 0.1 sec.
> >
> > That is the final piece of the jigsaw puzzle that I was looking for.
> > I noticed that Herman talks about executing when new quotes are
> > received ... is there any way to know when a quote (tick) has
> > arrived other than Status("redrawaction")? ... this seems to be a
> > generic trigger so we can't separate new quote from the other
> > possible causes of actioned refresh.
> >
> > My first impression is that progammatically creating panes with
> > functions to specify different refresh the individual panes would be
> > on the short wishlist of RT high performance traders, or not?
> >
> > I noticed that a lot of your posts are educational.
> > Thanks once again to you and Herman for your efforts to educate
> > others (there were some good contributions from others in the posts
> > I read to).
> >
> > Correction to my previous post:
> >
> > It seems that the best way to go is to work with an amount of data
> > that fits into the cache (I think that is for all symbols in the
> > database).
> > So, it follows that the best case is to only save new data that
> > arrives in memory at the end of the session.
> > This could vary though ... perhaps AB does this on time OR it would
> > be forced to do this if data starts to overflow the cache (the
> > unknown factor there is how AB differentiates new data in memory
> > from the data that we loaded into the cache from the disc. Most
> > likely it marks start of the new data in some way ... I don't think
> > the optimum method would be to save all the data in memory by
> > default i.e. overwrite the data that we loaded in the first place).
> >
> > --- In amibroker@xxxxxxxxxxxxxxx, Dennis Brown <see3d@> wrote:
> >>
> >> Brian,
> >>
> >> If you go to the data provider's sites, they tell you exactly what
> >> they provide and archive. In general a RT data provider will keep a
> >> number of days of tick history. From those they compress into one
> >> minute bars that they keep for many months or a few years. From
> >> those, they compress into daily bars that they keep for many years or
> >> decades. They will provide historical downloads based on one of
> >> these
> >> saved formats. Some also compress ticks into volume bars of various
> >> denominations for certain tickers that they archive like minute bars.
> >> They just have these few historical formats and everything else has
> >> to
> >> be aggregated from these, either by the server, or the client. WIth
> >> storage becoming less expensive, the tendency is to keep larger
> >> historical archives.
> >>
> >> It is possible that for efficiency, they might choose to cache other
> >> tick derived timeframes like 5 second, etc., so they don't have to
> >> duplicate the computations on every request. However, that is
> >> internal and may or may not take place based on their internal
> >> engineering designs, and it may change at any time. They also scrub
> >> their databases for bad ticks during the day and also at night. This
> >> obviously means that the data you get served for a historical
> >> backfill
> >> will not match the data that actually occurred in real time.
> >>
> >> BTW: The backtests can show good trading performance that is not
> >> duplicated in realtime. This is a possible indication of an over
> >> optimized algorithm. I try to avoid such algorithms in practice.
> >> The
> >> way you find out is to run the algorithm in realtime for a day, then
> >> backfill over the day's data the next day and see if the performance
> >> changes significantly. I learned this lesson early on the hard way.
> >> This was actually a major driver for me to trade only the ES futures
> >> -- the data feeds are very high quality with very few errors, so my
> >> backtests match the realtme trading performance. For very high speed
> >> trading Herman has many more caveats in the UKB.
> >>
> >> RequestTimedRefresh can only specify down to 1 second in 1 second
> >> increments. It also has two other useful modes that are not time
> >> based. The 0.1 second refresh minimum time can only be achieved when
> >> refreshes are triggered by new quotes (ticks) in the data stream at a
> >> rate equal or less than 0.1 sec. To have timed refreshes at 0.1
> >> second increments is only something that has been requested at this
> >> point.
> >>
> >> BR,
> >> Dennis
> >>
> >> On Jul 5, 2009, at 5:14 AM, brian_z111 wrote:
> >>
> >>>> since their server is, say tick based, when we use it at a
> >>>>> different timeframe
> >>>> (as the base timeframe in AB) then AB must compress ticks, on the
> >>>>> fly in memory
> >>>> UNLESS they keep different timeframes on different servers, or
> >>>>> sections of
> >>>> servers, but that doesn't seem likely.
> >>>
> >>> Actually, now that I think about it the most likely scenario appears
> >>> to be that the providers compress their tick data according to our
> >>> needs (AB communicates with them via the plugin and 'tells' the
> >>> provider what timeframe we want to use).
> >>>
> >>> --- In amibroker@xxxxxxxxxxxxxxx, "brian_z111" <brian_z111@> wrote:
> >>>>
> >>>> Tomasz,
> >>>>
> >>>> Thanks.
> >>>>
> >>>> I am starting to understand now because I have read a few of the
> >>>> posts on refresh etc (thanks to Herman/Dennis .. who seem to be the
> >>>> leaders on this, and others plus, of course, your good replies,
> >>>> here and there).
> >>>>
> >>>> I seem to have moved on to AFL 201, without even noticing.
> >>>>
> >>>> I don't understand why you did not tell me this stuff in the
> >>>> manual... I could have learnt it years ago instead of suffering it
> >>>> out in silence.
> >>>> I had to access posts to find it out ... it took me a few hours ..
> >>>> will I remember what I read, or do I have to archive the posts ..
> >>>> maybe try to find them again if I forget (more precious time
> >>>> gone) ... * how many users have to do this per year?
> >>>>
> >>>> In general I agree with your philosophies and approach ... I give
> >>>> AB a tick for QuickAFL and setting the default to 0.1 sec refresh
> >>>> with > 0.1 chart redraw required. This is practical and logical and
> >>>> a very good yardstick for non-programmers. Most long term users
> >>>> will want to go further though ... even the non-progamming group
> >>>> will start asking questions eventually.
> >>>>
> >>>> I don't agree with all of your answers though ... some are
> >>>> questionable ... not technically questionable but in terms of your
> >>>> objectives, yes questionable .... but at this stage I haven't made
> >>>> a final decision:
> >>>>
> >>>>
> >>>> I don't need this stuff myself, not at the moment, but I have to go
> >>>> along with any investigation into the power of the logic.
> >>>>
> >>>>
> >>>> (The Holy Grail for my style is to make 1000%PA, in consecutive
> >>>> years, and only need a little bit of code in an AB chart OR maybe
> >>>> no AB at all ... except that AT is permissable because it is only a
> >>>> tool to ease the administrative burden).
> >>>>
> >>>> For this discussion I referenced the following posts:
> >>>>
> >>>> http://finance.groups.yahoo.com/group/amibroker/message/137507
> >>>> http://finance.groups.yahoo.com/group/amibroker/message/122464
> >>>> http://finance.groups.yahoo.com/group/amibroker/message/109672
> >>>> http://finance.groups.yahoo.com/group/amibroker/message/125914
> >>>> http://finance.groups.yahoo.com/group/amibroker/message/136087
> >>>> http://finance.groups.yahoo.com/group/amibroker/message/135943
> >>>>
> >>>>
> >>>>
> >>>> KEYWORDS
> >>>>
> >>>> OPTIMAL RT PERFORMANCE
> >>>>
> >>>>
> >>>>
> >>>> OT Commentary:
> >>>>
> >>>> Don't worry, Tomasz.
> >>>>
> >>>> Even if you wrote an explanation of the zillion of things that make
> >>>> AB work there are too many nice things to do with my life to sit
> >>>> down and read them all.
> >>>>
> >>>> I think that, in general, people only want to know, and need to
> >>>> know the basics of the core processes.
> >>>>
> >>>> You could easily add a chapter, on this subject, to the manual and
> >>>> add a flowchart or two (BTW the 'flowchart' for Database
> >>>> Management, in the manual, is too basic (junior school level).
> >>>> Do you realize the power that flowcharts have, to convey
> >>>> information?
> >>>> In the mining industry I have seen examples where all of the core
> >>>> information in a 1000 page manual was contained, in detail, in 20
> >>>> drafted charts ... a whole processing plant, covering 100's of
> >>>> hectares, summarized in around 100 - 200 charts (I could tell you
> >>>> exactly what was going on in any section of the plant without
> >>>> leaving my office).
> >>>>
> >>>>
> >>>> Re data collection:
> >>>>
> >>>> I was thinking about this yesterday, in the back of my mind.
> >>>> It is amazing how, after you formalize a question the answer starts
> >>>> to form in your mind, all by itself.
> >>>>
> >>>> I came to the following speculative construction in my imagination
> >>>> (that is the picture in my head for laypeople) ... the picture is
> >>>> constructed by relying on what is the most likely or at least a
> >>>> feasible way that soemthing could be done:
> >>>>
> >>>> - streaming data can be collected passively ... I imagine it is
> >>>> like water, in a tap, that is under pressure, and if we tap into it
> >>>> then it will flow to us (don't know how it would work technically).
> >>>> I imagaine that providers would use this method as it would be an
> >>>> efficient way to get the data to many users (it requires less
> >>>> activity on their servers?)
> >>>>
> >>>> - in AB, data collection is managed by the program ..... the
> >>>> plugins are relatively dumb (they just have the docking protocols
> >>>> etc?)
> >>>>
> >>>> - routines to manage each plugin are included in AB, and are
> >>>> activated when we install the plugin OR when we install the plugin
> >>>> it adds a little bit of plugin control code to AB so AB can
> >>>> interact with it
> >>>>
> >>>> - IQ, for example, is streaming data, and the data flows from their
> >>>> server into our on board cache, when we are connected via the
> >>>> plugin
> >>>>
> >>>> - ticks go into the on board memory in the order they arrive (park
> >>>> them on the end of the queue for each symbol)
> >>>>
> >>>> - tick history in memory is rendered as Time&sales
> >>>>
> >>>> - tick history is only rendered for the QuoteWindow and charts
> >>>> according to refresh rates, so while tick history is there (for
> >>>> Time and Sales and historical work) we don't see it in RT work.
> >>>>
> >>>> - Tools > Preferences > Intraday > Realtime Chart Refresh interval
> >>>> (sec) is the default for chart and QuoteWindow refresh/
> >>>>
> >>>> - RequestTimedRefresh over-rides the preference setting for charts
> >>>> (not sure about QuoteWindow ... I guess not).... it accepts any
> >>>> input but in practice it is limited to 0.1 sec by AB
> >>>>
> >>>> - newly arrived tick data, in the onboard cache, is only saved to
> >>>> the historical database, on the disc, when we hit save OR when we
> >>>> exit the database/session (only if autosave is set in our
> >>>> preferences?)
> >>>>
> >>>>
> >>>> - IQ, for example, is a streaming RT tick provider ... each new
> >>>> tick must pulse to us but at the same time go to their historical
> >>>> database so that we can download historical (backfill) by sending a
> >>>> request to their server
> >>>>
> >>>> - since their server is, say tick based, when we use it at a
> >>>> different timeframe (as the base timeframe in AB) then AB must
> >>>> compress ticks, on the fly in memory UNLESS they keep different
> >>>> timeframes on different servers, or sections of servers, but that
> >>>> doesn't seem likely.
> >>>>
> >>>> - after hours, when traffic is light, AB changes over to the
> >>>> default of 'polling' the server once every sec (like requesting a
> >>>> backfill of historical data).
> >>>>
> >>>> Of course, this could all be wrong ... it is only speculation.
> >>>>
> >>>> We only speculate, in an effort to gain understanding, in the
> >>>> absence of truth (we are all driven towards achieving
> >>>> understanding, or meaning, fo the world around us, or our current
> >>>> environment. This is hardcoded into humans).
> >>>>
> >>>>
> >>>> Why do I want to know this stuff?
> >>>>
> >>>> - so that I can use AB in better ways (if I understand the design
> >>>> limits I will know how far I can push it in any one direction).
> >>>> - and so that I don't have to ask stupid questions in the forum
> >>>> - because quite a few experienced AB users are sometime confused
> >>>> by/
> >>>> interested in this subject
> >>>>
> >>>> for example:
> >>>>
> >>>> in 3-4 years of owning AB I have never used PerformanceCounter, or
> >>>> debug or CodeProfile and check etc ... not once, because you didn't
> >>>> put it in pictures in the manual. In the first years, because of my
> >>>> computing inexperience, I couldn't absorb this info, by the 'no
> >>>> hand holding here' method because there was too much other stuff to
> >>>> learn ... my brain couldn't cope with that kind of workload i.e.
> >>>> you have answered questions on Refresh before but I didn't follow
> >>>> the answers because I didn't realize the significance (you need
> >>>> your specs to find your specs) ... on the other hand if your write
> >>>> about it in the Help maual then I know that it must be significant
> >>>> so then I will pay more attention e.g. if you don't write about
> >>>> Code Profile and Check then I guess that it is not a significant
> >>>> part of AB.
> >>>>
> >>>> Why do I ask these questions here?
> >>>>
> >>>> - because it would be very selfish, and an inefficient use of AB
> >>>> time (== bad karma!) if I emailed support and kept the answers to
> >>>> myself.
> >>>> - because I am a NewAgeGuy (not a sensitive one though) I am
> >>>> committed to my ethical imperatives ..... group effort and sharing,
> >>>> transparent communication and full disclosure/availability of
> >>>> information.
> >>>>
> >>>>
> >>>> I do notice your admonitions, and guidance, in this forum, not to
> >>>> do certain things in AB e.g. I saw your post advising that total
> >>>> execution (redraw time) should be under 0.1 sec and this fits
> >>>> nicely with your default time of 0.1 sec for refresh.
> >>>> I really appreciate your guidance in these areas.
> >>>> I have learnt a lot about the IT side of trading, from you ...
> >>>> taking not of the things you put in and left out of AB and also the
> >>>> forum discussions.
> >>>> I should have archived some of your answers but once again that is
> >>>> additional work to compile my own private Help manual.
> >>>>
> >>>>
> >>>> FTR
> >>>>
> >>>> why do you only give your answers informally, via the forum,
> >>>> instead of compending them somewhere, for the benefit of newcomers
> >>>> and for reference ... why do youkeep on answering the same
> >>>> questions in the forum ... over and over again?
> >>>>
> >>>> Do you ever feel the urge to answer these questions once and for
> >>>> all and then the users can move on?
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> --- In amibroker@xxxxxxxxxxxxxxx, Tomasz Janeczko <groups@> wrote:
> >>>>>
> >>>>> Hello,
> >>>>>
> >>>>> Chart refresh is independent from data collection.
> >>>>> It means that plugin can collect even 1000 updates (ticks) per
> >>>>> second
> >>>>> per symbol,
> >>>>> while chart will refresh 10 times per second.
> >>>>>
> >>>>> If that happens, during 0.1 sec you will see 100 new ticks arrived
> >>>>> and
> >>>>> displayed
> >>>>> on chart.
> >>>>>
> >>>>> It does not make sense to update chart more often than about 10
> >>>>> times
> >>>>> per second
> >>>>> because human perception is limited to that rate.
> >>>>>
> >>>>> Best regards,
> >>>>> Tomasz Janeczko
> >>>>> amibroker.com
> >>>>>
> >>>>> brian_z111 wrote:
> >>>>>> Going by what Tomasz said:
> >>>>>>
> >>>>>> Plugins do send updates if certain market is closed because
> >>>>>> a) if you open AmiBroker on sunday, you still want to see most
> >>>>>> recent quote,
> >>>>>> without waiting till Monday.
> >>>>>> b) plugins not only send updates on quotes but also on some other
> >>>>>> info that is
> >>>>>> not related to market activity
> >>>>>> c) there can be corrections sent later
> >>>>>> d) other markets may be open
> >>>>>> e) the bacfill may be in progress, etc.
> >>>>>>
> >>>>>> For the reasons above, most plugins sent "general update" every
> >>>>>> second.
> >>>>>>
> >>>>>> AND "real-time data refresh (can be as often as every tick, but
> >>>>>> not more often
> >>>>>> than 10 times per second)"
> >>>>>>
> >>>>>> For IQ RT data:
> >>>>>>
> >>>>>> - when the market is quiet we are receiving general updates, in
> >>>>>> our charts, every sec and when the market is busy we are
> >>>>>> receiving updates every 1/10th sec, at best i.e. if watching a
> >>>>>> fast market and we have no programmatical or preferences set to
> >>>>>> refresh AND we don't touch our mouse).
> >>>>>>
> >>>>>> This seems to indicate that our data is polling the IQ server for
> >>>>>> a timeslice of historical tick downloads.
> >>>>>>
> >>>>>> Presumably our quote database and the T&S window is the same ...
> >>>>>> unless the plugin is a 'two in one' i.e. it does it one way for
> >>>>>> charts and another way for T&S or quote database.
> >>>>>>
> >>>>>>
> >>>>>> --- In amibroker@xxxxxxxxxxxxxxx, "brian_z111" <brian_z111@>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> RT speed (trading in charts) seems to be limited,at the core, by
> >>>>>>> data speed.
> >>>>>>>
> >>>>>>> There are some things I don't understand about data and the way
> >>>>>>> we collect it, via our plugins.
> >>>>>>>
> >>>>>>> I am referencing info from a previous discussion:
> >>>>>>>
> >>>>>>> http://finance.groups.yahoo.com/group/amibroker/message/136651
> >>>>>>>
> >>>>>>> I understand that these are hard questions to answer so if I get
> >>>>>>> no answer I will send the question to support.
> >>>>>>>
> >>>>>>> Assuming that for speed work, true tick data is the best (not 1
> >>>>>>> -5 sec snapshot like some data providers).
> >>>>>>>
> >>>>>>>
> >>>>>>> Assuming that the plugins are not all the same ... they are
> >>>>>>> matched to the data type.
> >>>>>>>
> >>>>>>> Is it possible for software to be a passive receiver of RT data
> >>>>>>> i.e. the provider 'sends' out the ticks, like a pulse, and we
> >>>>>>> just hook up our pipe (via the plugin) and the data streams into
> >>>>>>> our software (is that what is called streamed data?)
> >>>>>>>
> >>>>>>> If so, would they 'pulse' every tick but not supply historical
> >>>>>>> ticks live?
> >>>>>>>
> >>>>>>> Opposed to 'streaming' data I imagine that the provider could
> >>>>>>> just give us access to the historical ticks (with RT update) and
> >>>>>>> we have to proactively get the data i.e. our plugin would
> >>>>>>> initiate a download of the last few ticks or secs of tick data.
> >>>>>>>
> >>>>>>> I am a bit confused about this.
> >>>>>>>
> >>>>>>> Using IQFeed as the example:
> >>>>>>>
> >>>>>>> - it appears that our IQ plugin 'polls' the IQ server OR holds
> >>>>>>> the streaming data for a while and then sends it to us in
> >>>>>>> packets.
> >>>>>>>
> >>>>>>> Tomasz said that
> >>>>>>>
> >>>>>>> "real-time data refresh (can be as often as every tick, but not
> >>>>>>> more often
> >>>>>>> than 10 times per second)"
> >>>>>>>
> >>>>>>> but in a test, Conrad Joach (using IQ RT data) with refresh in
> >>>>>>> the preferences set to zero, found that the plugin was updating
> >>>>>>> to AB every second (this is plugin initiated activity ...
> >>>>>>> completely independent of refresh settings and not requested
> >>>>>>> refresh in the AFL formula).
> >>>>>>>
> >>>>>>> Is the IQ plugin streaming every tick OR polling every 10 secs
> >>>>>>> OR polling every 1 sec Or something else?
> >>>>>>>
> >>>>>>> To make things even more confusing Tomasz also said that
> >>>>>>>
> >>>>>>> "On MSFT you can easily have more than 200 new ticks per second.
> >>>>>>> Use Time&Sales window to display actual ticks."
> >>>>>>>
> >>>>>>>
> >>>>>>> If MSFT has > 200 ticks per second does that mean we can never
> >>>>>>> see true RT tick by tick charts because our plugin only updates,
> >>>>>>> at best 1 per sec or 1 per 10 sec (not sure which is correct).
> >>>>>>>
> >>>>>>> Also, how can we see ticks for say, MSFT, in the Time&sales
> >>>>>>> window (I don't use it so I am not sure if we can or not).....
> >>>>>>> are we really only seeing historical bites in the T&S window OR
> >>>>>>> is the plugin somehow streaming ticks to the T&S window while
> >>>>>>> not streaming ticks to our charts?
> >>>>>>>
> >>>>>>>
> >>>>>>> (I am using Pro 5.20 on an XP machine)
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> ------------------------------------
> >>>>>>
> >>>>>> **** IMPORTANT PLEASE READ ****
> >>>>>> This group is for the discussion between users only.
> >>>>>> This is *NOT* technical support channel.
> >>>>>>
> >>>>>> TO GET TECHNICAL SUPPORT send an e-mail directly to
> >>>>>> SUPPORT {at} amibroker.com
> >>>>>>
> >>>>>> TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER at
> >>>>>> http://www.amibroker.com/feedback/
> >>>>>> (submissions sent via other channels won't be considered)
> >>>>>>
> >>>>>> For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
> >>>>>> http://www.amibroker.com/devlog/
> >>>>>>
> >>>>>> Yahoo! Groups Links
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>> ------------------------------------
> >>>
> >>> **** IMPORTANT PLEASE READ ****
> >>> This group is for the discussion between users only.
> >>> This is *NOT* technical support channel.
> >>>
> >>> TO GET TECHNICAL SUPPORT send an e-mail directly to
> >>> SUPPORT {at} amibroker.com
> >>>
> >>> TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER at
> >>> http://www.amibroker.com/feedback/
> >>> (submissions sent via other channels won't be considered)
> >>>
> >>> For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
> >>> http://www.amibroker.com/devlog/
> >>>
> >>> Yahoo! Groups Links
> >>>
> >>>
> >>>
> >>
> >
> >
> >
> >
> > ------------------------------------
> >
> > **** IMPORTANT PLEASE READ ****
> > This group is for the discussion between users only.
> > This is *NOT* technical support channel.
> >
> > TO GET TECHNICAL SUPPORT send an e-mail directly to
> > SUPPORT {at} amibroker.com
> >
> > TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER at
> > http://www.amibroker.com/feedback/
> > (submissions sent via other channels won't be considered)
> >
> > For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
> > http://www.amibroker.com/devlog/
> >
> > Yahoo! Groups Links
> >
> >
> >
>
------------------------------------
**** IMPORTANT PLEASE READ ****
This group is for the discussion between users only.
This is *NOT* technical support channel.
TO GET TECHNICAL SUPPORT send an e-mail directly to
SUPPORT {at} amibroker.com
TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER at
http://www.amibroker.com/feedback/
(submissions sent via other channels won't be considered)
For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
http://www.amibroker.com/devlog/
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/amibroker/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/amibroker/join
(Yahoo! ID required)
<*> To change settings via email:
mailto:amibroker-digest@xxxxxxxxxxxxxxx
mailto:amibroker-fullfeatured@xxxxxxxxxxxxxxx
<*> To unsubscribe from this group, send an email to:
amibroker-unsubscribe@xxxxxxxxxxxxxxx
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|