Hello, As I wrote - if you need buttons on chart screen, I can consider adding support for real (i.e. windows control) buttons. They would not require any handling of up/down state in low-level gfx because imagery and behaviour of buttons is done by OS.
It would look something like that: x = ControlButton( "caption", id, xpos, ypos, width, height, flags, textcolor = colorDefault ); // id - unique identifier (simple number like 1, 2, 3, 4, ....) and returned value x will hold the state of button (up/down, etc) The formula would be executed automatically on button click. Best regards, Tomasz Janeczko amibroker.com On 2010-06-19 12:19, Rob wrote: > There was a bug in the Param window functionality that caused 'ghost > parameters' when new Param lines were added and removed from code. It lead to > corrupted parameter lists which then required resetting with 'reset all'.... > However, I believe TJ fixed this bug recently. > I have not seen it since. > > I too use GFX functions to provide on charts buttons for real time trading > operation... They work fine for me because I have optimized my code, and 1 > sec refresh is fine for my purposes. > > However, I do have to agree that for real time operation the Param window is > clunky and awkward and simply doesn't do the job as a day trader example. > It's great for setting parameters in a non-time dependent situation... but > not in time dependent situations. > > > > --- In [email protected], Tomasz Janeczko<gro...@...> wrote: > >> Hello, >> >> >>> It bas bugs (requires frequent Reset-Alls because the parameters are >>> >> corrupted >> >> I did not see any case of parameter window corruption if Param() >> functions are used correctly (i.e. they are put on global level and you >> don't modify parameter names on-the-fly during formula executions - >> those operations were never allowed and can not be considered as bugs). >> >> >> >>> it doesn't remember collapsed/expanded states, >>> >> It never supposed to remember that. By design they are expanded to make >> sure that novices are aware that there are parameters in the sections. >> Otherwise novice user may not know that it has to click to reveal >> underlying parameters. >> >> >>> doesn't allow colors, >>> >> It is also not a bug. Windows UI design guidelines say that UI controls >> should have consistent colors in entire system and all OS. The colors >> used are system colors set in Windows Control Panel. >> >> >>> it is slow to use, >>> >> I don't know what you mean here. One line Param() function >> x = Param("period", 5, 1, 100, 1 ); >> >> is slow to use ? >> Or do you mean that single click is slow to use? >> >> >>> is very large in terms of screen estate, etc. >>> >> It is resizable. You can shrink it to resonable minimum. >> >> >>> Sorry, this has been mentioned many times before, but the Param window >>> >> is unsuitable for any complex real-time trading interface. >> >> Generally I don't agree with crushing critique of Param window presented >> in your letter. >> >> UI interfaces should not be created from scratch using Gfx functions >> because they are not designed for this purpose. >> UI interfaces in Windows are created using Windows controls, see: >> http://msdn.microsoft.com/en-us/library/bb773173(VS.85).aspx >> >> We can discuss whenever AFL should allow putting some windows controls >> onto chart window to allow "custom" UIs, but handling everything on very >> low level using gfx functions and tracing mouse movement and clicks is >> not good because it unnecessarily consumes CPU. Your UI would be much >> more responsive if it used windows controls and would behave as 'real' >> application. >> >> Best regards, >> Tomasz Janeczko >> amibroker.com >> >> On 2010-06-19 00:47, Herman wrote: >> >>> >>> Welcome back Tomasz! >>> >>> The Param window is only suited for simple applications like indicator >>> adjustments. It bas bugs (requires frequent Reset-Alls because the >>> parameters are corrupted, it doesn't remember collapsed/expanded >>> states, doesn't allow colors, it is slow to use, is very large in >>> terms of screen estate, etc. Sorry, this has been mentioned many times >>> before, but the Param window is unsuitable for any complex real-time >>> trading interface. >>> >>> The gfx functions provide marvelous opportunities to create >>> mind-blowing interactive GUIs but are crippled due to inability to >>> refresh a pane on command. One second is far too slow for real-time >>> applications. I use about 30 different types of control buttons, some >>> click and some hover sensitive, some with 10-item auto drop down >>> menus, and I have an interactive table with 100+ click sensitive >>> cells. All this works nice and pretty fast in terms of execution times >>> (30 mSec). But performance is crippled by the slow 1-sec refresh rate. >>> >>> A reasonable solution would be to provide an advanced setting for >>> pro-users to allow, under certain conditions, faster refreshes at 10/sec. >>> >>> To prevent misuse you could enable this feature only when the mouse is >>> moving or clicked, and hold the higher-rate refreshes for one second >>> after the last mouse action to allow users to perform a sequence of >>> actions. I am sure there are a dozen ways to implement this. >>> >>> A scheme like this would satisfy advanced-user demands, open up the >>> sky to innovative gfx applications, and _make it impossible_ for users >>> to go into a loop "thousands of times". >>> >>> What do you think? >>> >>> Best regards, >>> herman >>> >>> >>> >>> >>> >>> Hello, >>> >>> Single-pane chart refresh is available via RequestTimedRefresh. >>> It allows to refresh as often as every second. >>> It refreshes periodically. Refreshing "immediately" would inevitably >>> lead to infinite loop (refresh-execution-refresh-execution-.... >>> repeated thousands times per second) and locking up CPU (so called >>> busy wait loop). >>> It was possible in the past (5 years ago or so) using RefreshAll and I >>> got dozens of "bug reports" when users simply created codes that >>> triggered such infinite refresh loop locking up all computer resources >>> and not being able to stop this. Since then RefreshAll also includes >>> protection against refreshing too often precisely to prevent users >>> from shooting themselves in the foot by writing incorrect code. >>> >>> GUI should rather be created using Parameters window. >>> >>> Best regards, >>> Tomasz Janeczko >>> amibroker.com >>> >>> On 2010-06-18 22:28, Herman wrote: >>> >>> Thank you Keith but this refresh must be afl invoked. I am thinking of >>> "mouse-click" because this invokes an immediate pane-only refresh, I >>> can think of no other function that does that. The idea is to be able >>> to keep refreshing the chart at, say, 10xSec during mouse input. This >>> would allow creating very nice interactive GUIs. >>> >>> I think Keith's idea might work if we place the AlertIf() at the end >>> of the code.... >>> >>> herman >>> >>> >>> >>> >>> >>> >>> >>> Herman -- >>> Have you considered using Auto Hotkey. It can produce mouse clicks >>> and has some timing control and looping. >>> I have never used it myself. But I know others on this forum have. >>> -- Keith >>> >>> On 6/18/2010 14:23, Herman wrote: >>> >>> Thank you for your reply Chris, >>> >>> If we had an afl-controlled chart refresh we could create much more >>> "responsive" GUIs. This is a missing function in the gfx library. >>> Right now gfx functions, like dragging items, using a slider, dropping >>> down menus, adjusting params, etc. are all "hesitant" because they >>> have to wait for the next refresh to show the new graphics. I have too >>> many parameters and functions to use the AB Param window, its just too >>> big. RefreshAll() is too slow because it refreshes everything; I just >>> want to refresh the selected pane. >>> >>> I am not sure the AlertIf() would work because it is probably sampled >>> at the next refresh and the delay would still be there. If it is easy >>> for you to create an .exe I am willing to try it. >>> >>> I am not entirely sure how to solve this, perhaps i am just >>> programming it the wrong way... or wanting to do too much. >>> >>> Thanks for the idea Chris, >>> >>> herman >>> >>> >>> >>> >>> >>> *> Herman, >>> >>> >>>> I can think of this, possibly, as a solution: >>>> >>> >>>> (a) Use alertif to run a .exe that clicks the mouse. You can create >>>> >>> a .exe >>> >>>> that clicks the mouse using something like vTask Studio. If you >>>> >>> don't have >>> >>>> it, I can create that .exe and email it to you >>>> >>> >>>> May I ask you a question? Are you trying to get refreshes more >>>> >>> frequently >>> >>>> than executed ticks so that you can act on book changes before the tick? >>>> I've pondered how to do this in amibroker for some time, as by >>>> >>> design, the >>> >>>> screen refreshes upon tick execution (or requested time refresh of each 1 >>>> second). Seems to me that there might be one other way of doing it, and >>>> that is by: >>>> >>> >>>> (b) running js that draws upon Amibroker AA (via OLE automation) every so >>>> often. I haven't tried this at very frequent refresh interverals (eg< 1 >>>> sec) >>>> >>> >>>> Best, >>>> >>> >>>> Chris >>>> >>> >>>> ----- Original Message ----- >>>> From: "Herman"<psy...@...<mailto:psy...@...>> >>>> To: "AmiBroker User Group"<[email protected] >>>> >>> <mailto:[email protected]>> >>> >>>> Sent: Friday, June 18, 2010 2:12 AM >>>> Subject: [amibroker] Simulating a mouseclick from afl >>>> >>> >>> >>>>> Hello, >>>>> >>> >>>>> I often have a need to refresh the selected chart from afl, for >>>>> example to create responsive GUIs. >>>>> >>> >>>>> I have seen code to simulate key-strokes, would anyone know if it is >>>>> possible to simulate a Mouse-click from afl? >>>>> >>> >>>>> Many thanks for any help you can give, >>>>> >>> >>>>> Herman >>>>> >>> >>> >>> >>> >>> >>>>> ------------------------------------ >>>>> >>> >>>>> **** 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 >>>> >>> >>> >>>> [email protected] >>>> >>> <mailto:[email protected]> >>> >>> >>> * >>> >>> >>> >>> >>> >>> >>> >>> >> > > > > ------------------------------------ > > **** 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 > > > > >
