Hello, There have been several suggestions in the AB Feedback Center and in many postings on the forum regarding gfx menu buttons. TJ's reaction has been the same from the very beginning "gfx menus have been grossly abused by users". I have to admit that TJ has been right, but so far there have NOT been any other alternatives to create menus in AB. TJ used to recommend using Parameters instead of menus and although menu buttons closely resemble Parameters (e.g. TriggerButton -> ParamTrigger; RotateButton -> ParamList and ParamToggle; TextButton -> ParamSTR and ParamTime and ParamDate, but without the ability to change the content) there are significant differences between Parameters and menus.
1. Parameters were designed to manipulate the graphical output of the indicator and therefore all of them are active at all time. List of Parameters for an indicator is STATIC (number of parameters is fixed) and it cannot be changed. Menus, by nature are generated dynamically - at any time number of columns and / or number of buttons in columns can be different. Since a button represents some kind of a Parameter, this would mean that the number of Parameters is variable and this is not supported by the current version of AB. A typical example would be: "How many TRADES would you like to have ?" and then "What is the QUANTITY for each TRADE ?" . This concept is not implementable currently in AB due to fix number of Parameters for a given indicator. Since menus are generated dynamically it is easy to get "How many Trades" input first and then generate as many "Quantity" inputs as many Trades in step 1. 2. Parameters are not related to one another in any sense (they are just listed), therefore it is not possible to group them together and consequently perform any functions on that group (e.g. hide, expand, collapse, etc). 3. Using the current Parameter concept for trading purposes is not practical. Imagine a need for 20 trades and 15 parameters for each trade -> that's 300 Parameters in one window (!!!!!) how practical is it ? The concept of fix number of parameters forces any design to shoot for the worst possible scenario, which is always an overkill and leads to a clumsy solution. 4. The recent TJ's proposal to use windows control buttons is absolutely GREAT as long as an "INPUT" function is provided to support entry from the keyboard. The current examples of gfx menu functions in UKB DO NOT have this capability therefore any need of ENTRY still requires the use of Parameters and consequently a FIX number of parameters. 5. What differentiates menus from Parameters is the ability of applying a structure to a set of Parameters by creating groups (columns) and by generating the structure dynamically (variable number of Parameters). 6. Basic functionality: expand/collapse menu columns identified by Headers, generate column content (any kind of Parameter including INPUT (PARAM) with the exception of ParamColor, ParamStyle) with attributes like: active / inactive, select from a list, change color / label. I have been dreaming about generating dynamic menus and monitoring tools for trading purposes without using Parameters at all (I mean using the existing implementation of Parameters). So far, I have managed to generate menus dynamically with one exception there is no dynamic "INPUT", the input is trough PARAM. TJ, I can ensure you that I will be using Parameters when creating indicators for plotting purposes. They are great for these purposes. AF > > 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<groups@> 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"<psytek@<mailto:psytek@>> > >>>> 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 > > > > > > > > > > >
