Hello, Actually I decided to make it even simpler: GetCursorXPosition and GetCursorYPosition will return EMPTY (Null) values for all windows EXCEPT the one that received the mouse click.
There will be new parameter mode that will allow to get the co-ordinates in physical pixels as well and to switch to "old" mode (reporting X/Y pos always, regardless of clicked window). Best regards, Tomasz Janeczko amibroker.com ----- Original Message ----- From: Herman To: Tomasz Janeczko Sent: Wednesday, January 30, 2008 1:09 PM Subject: Re: [amibroker] Re: Trading platform + AB Thank you Tomasz :-) this is great news! Once we have the Window handle we can truly make AmiBroker "INTERACTIVE". Very sophisticated processes will become simple, single, mouse clicks. imo, wrt to scalping, Chart-Trading is really the thing of the future. In Amibroker it is possible to create VERY visually revealing charts/display that can be interpreted by the trader a hundred times faster that scrolling tables with lots of numbers - as some other software providers offer. I have tried it and the efficiency of using dynamic displays, colors, sounds, bar charts, price labels, you name it, is simply stunning. It is all possible in AB, is (again imo) far more intuitive than looking at complex charts and tables. so much to do, so little time ... Best regards, herman For tips on developing Real-Time Auto-Trading systems visit: http://www.amibroker.org/userkb/ Wednesday, January 30, 2008, 6:47:11 AM, you 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 > > http://groups.yahoo.com/group/amibroker/ > > Individual Email | Traditional > > http://groups.yahoo.com/group/amibroker/join > (Yahoo! ID required) > > mailto:[EMAIL PROTECTED] > mailto:[EMAIL PROTECTED] > > [EMAIL PROTECTED] > > http://docs.yahoo.com/info/terms/ >
