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]> > > > > > > * > > > > > > > > > > > > > > >
