|
PureBytes Links
Trading Reference Links
|
Hello,
I appreciate your feedback. Yes I fully agree about code examples.
Thank you for your kind words about AB.
As to last paragraph - with current inflation I guess it would not be very
wise move to sell profitable and expanding company as $$$ offered today
will be dilluted pretty fast. I belive that on the long run a good business is
the most safe, profitable and enjoyable way to grow your wealth.
I would paraphase "you don't sell the goose that lays the olden eggs".
Best regards,
Tomasz Janeczko
amibroker.com
----- Original Message -----
From: "scourt2000" <stevehite@xxxxxxxxxxx>
To: <amibroker@xxxxxxxxxxxxxxx>
Sent: Thursday, January 31, 2008 3:05 AM
Subject: [amibroker] Re: Trading platform + AB
>
> Thanks for the clarification Tomasz.
>
> You would get a lot of new business with direct chart trading
> capabilities.
>
> I think once all of the pieces are finally in place, you just need to
> put something together that's one level of abstraction up so common
> users aren't left with a bunch of basic parts and don't know exactly
> what to do with them. Formalize some templates that have some meat
> to them and you'll get all kinds of interest in this idea that
> equates to more subscriptions.
>
> The suggestions by Dennis were excellent too. People would want to
> use modifier keys in addition to mouse clicks so they could change
> the the type of order being placed.
>
> Tomasz, the one thing I love about your product is that you aren't
> extracting a pound of flesh from me on a monthly basis. Think of all
> of your competitors out there who are doing just that. You've been
> more than fair with your upgrade policies and you would certainly get
> more market share taken away from them by getting Amibroker into the
> chart-trading-with-multiple-brokerages world.
>
> Our only problem at that point would be a big company who would want
> to buy you out and you couldn't say 'no' to all of that money being
> thrown at you.
>
>
>
> --- In amibroker@xxxxxxxxxxxxxxx, "Tomasz Janeczko" <groups@xxx>
> wrote:
>>
>> Hello,
>>
>> The point is that you don't understand execution model of AB.
>> If you click on ANY place chart pane, all panes belonging to given
> chart are
>> refreshed. This is so because the SELECTED date/time changed for
> all panes
>> and you want your custom Title, chart values,
>> and indicators recalculated. There are many formulas that use
> SelectedValue()
>> to display things that depend on the selected date.
>>
>> AFL execution is ALREADY _event_ driven. It is NOT polled. It
> executes ONLY when there is an event
>> (mouse click, real-time refresh, zoom in/out, change of current
> symbol, user-defined timer (RequestTimedRefresh) etc).
>>
>> The callback idea on the surface looks attractive, but once
> implemented you wil
>> see yourself repeating lots of code or calling the same global
> functions over and over
>> again and this would inefficient.
>>
>> For example, let's say that your indicator that you use for trading
> takes 0.5 second
>> to execute.
>>
>> With current design, when mouse click occurs your indicator is
> calculated ONCE
>> and you can use its values stored in a variable for anything (draw
> chart, handle mouse clicks,
>> auto-trade, display alarms, perform more calculations) - all with
> ONE calculation
>> of your time-consuming indicator.
>>
>> If your call-back driven model was implemented after mouse click
> the following call back
>> functions would be called:
>>
>> OnLButtondDown
>> OnChartRefresh
>> OnNewDateTimeSelected
>>
>> And you would need to calculate your indicator THREE times in each
> function
>> if you want its values. This is because the callback approach
> assumes that
>> there is NO "global" code executed always. And this would be three
> times slower.
>>
>> Actually the whole distinction about this call-back thing is
> rather "philosophical"
>> because in practice in Windows the application has SINGLE
> application message loop (per thread)
>> and messages from ALL sources land in ONE queue that is handled
>> by one simple loop (see PeekMessage/GetMessage/DispatchMessage)
>> The message is pumped to active window.
>> All those call-backs and what you see in higher-level languages are
>> just functions called from big switch and/or message map (which is
> also switch / if-like construct)
>> that is inside WindowProc function that receives all messages.
>>
>> http://msdn2.microsoft.com/en-us/library/aa452701.aspx
>>
>> This has NOTHING to do with interrupts. Interrupts exist on PC
> platform on HARDWARE level
>> and are used by operating system only. Interrupts are asynchronous
> and one interrupt can
>> actually stop the execution of other code to handle the interrupt.
>> Message processing (what software applications do) is fully
> sequential and message processing is
>> NOT interrupted (i.e. one message must be fully processed before
> processing next one).
>> I am of course speaking what happens on single thread level (not
> couting that your app may be switched out by pre-emptive OS)
>>
>> For this reason, you can implement your "callback" approach by
> yourself, just write a switch
>>
>> Store code below in "myCallbackHandler.afl" file in the Include
> folder so you can use it whenever you want
>>
>> function EventHandler()
>> {
>> local b, x, y;
>> b = GetCursorMouseButtons();
>> x = GetCursorXPosition();
>> y = GetCursorYPosition();
>>
>> if( b & 1 ) OnLMouseButton( x, y );
>> if( b & 2 ) OnRMouseButton( x, y );
>> if( b & 4 ) OnMMouseButton( x, y );
>> }
>>
>>
>> EventHandler();
>>
>> Then in your formula put #include <mycallbackhandler.afl> at the
> END of the formula:
>>
>> function OnLMouseButton(x, y)
>> {
>> _TRACE("LButton x = " + DateTimeToStr( x ) + " y = " + y );
>> }
>>
>> function OnRMouseButton(x, y)
>> {
>> _TRACE("RButton x = " + DateTimeToStr( x ) + " y = " + y );
>> }
>>
>> function OnMMouseButton(x, y)
>> {
>> _TRACE("MButton x = " + DateTimeToStr( x ) + " y = " + y );
>> }
>>
>> Graph0=C;
>>
>> #include <mycallbackhandler.afl>
>>
>>
>> And Herman is CORRECT in his response. The only thing needed to
> actually know to make it work
>> perfectly is window handle that received the mouse click (chartID
> is not enough as there can be
>> two panes shareing the same). The ability to know window handle
> that received mouse click will be added.
>>
>> Best regards,
>> Tomasz Janeczko
>> amibroker.com
>> ----- Original Message -----
>> From: "scourt2000" <stevehite@xxx>
>> To: <amibroker@xxxxxxxxxxxxxxx>
>> Sent: Wednesday, January 30, 2008 2:51 AM
>> Subject: [amibroker] Re: Trading platform + AB
>>
>>
>> >
>> > "This can be done now using GetCursorMouseButtons(),
>> > GetCursorXPosition() and GetCursorYPosition() . HOWEVER there is
> no
>> > function that returns the ChartID for the chartpane over which
> the
>> > mouse is clicked"
>> >
>> > Hi Herman,
>> >
>> > All of that chartID stuff would not be necessary if you tied the
>> > mouse button clicks to well-known event routines (like that ones
> I
>> > mentioned as an example) which get called specifically from the
> AFL
>> > code behind a chart pane.
>> >
>> > You want this type of facility event-driven, not polled. Polling
>> > puts more work on the user's side and brings up other unpleasant
> side-
>> > effects like what you just described.
>> >
>> > Which would you rather do?
>> >
>> > 1) Code a rats nest of polling inline with your other AFL code
>> >
>> > -or-
>> >
>> > 2) Have a well-known function called on a mouse click with all of
> the
>> > information you need provided as the function parameters directed
> to
>> > the script already bound to a particular chart pane?
>> >
>> > Anyone who chooses #1 last seriously programmed a computer more
> than
>> > 20 years ago.
>> >
>> > "That's available now - check the list of functions, duude."
>> >
>> > No it's not...duude [sic]
>> >
>> >
>> >
>> > Please note that this group is for discussion between users only.
>> >
>> > To get support from AmiBroker please send an e-mail directly to
>> > SUPPORT {at} amibroker.com
>> >
>> > For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
>> > http://www.amibroker.com/devlog/
>> >
>> > For other support material please check also:
>> > http://www.amibroker.com/support.html
>> >
>> > Yahoo! Groups Links
>> >
>> >
>> >
>>
>
>
>
>
> Please note that this group is for discussion between users only.
>
> To get support from AmiBroker please send an e-mail directly to
> SUPPORT {at} amibroker.com
>
> For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
> http://www.amibroker.com/devlog/
>
> For other support material please check also:
> http://www.amibroker.com/support.html
>
> Yahoo! Groups Links
>
>
>
Please note that this group is for discussion between users only.
To get support from AmiBroker please send an e-mail directly to
SUPPORT {at} amibroker.com
For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
http://www.amibroker.com/devlog/
For other support material please check also:
http://www.amibroker.com/support.html
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/
|