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" <[EMAIL PROTECTED]> To: <[email protected]> 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 [email protected], "Tomasz Janeczko" <[EMAIL PROTECTED]> > 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" <[EMAIL PROTECTED]> >> To: <[email protected]> >> 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 > > >
