I have created a feature request on reddit for this:(https://www.reddit.com/r/TradingView/comments/xh0ixf/strategy_orders_via_once_per_bar_trigger/)
But thought maybe someone knows if there is a workaround for this? The strategy engine works only per candle bar close, but it would be really awesome if it would be possible to open/close strategy orders while candle bar is still open and price is touching a certain point/line/etc. Basically the same way you can set an alert with Once Per Bar option, so that you are notified exactly when price is touching/crossing a certain point/line during candle bar still running, before it actually closes.
Related
In an Entity Component System, what's the correct way to create a cooldown timer that has a display element that could be attached to a button for example?
My initial thought is to separate out the timer and progress bar components individually whereby the timer either delegates back to the entity to update a progress bar via a specific number/percentage or the timer tries to grab the correct component from the entity itself and update it. This way I've split up all the concerns into separate components. But should this actually all be in one component such as a timerProgressBarComponent seen as it's "one job". Ideally this will add a display element to an existing sprite to showcase how long is left.
In case you want some more context, I'm thinking in terms of a button at the moment that can only be pressed every 10 seconds, but I want to update the ui with an indication of how long is left and once the 10 seconds is up make the button tappable again.
There is no "correct way" only what you prefer. If I was doing this, I would separate out timer to allow for various types of progress bars, but that does not mean that it is not feasible for a progress bar to contain its own timer and still act as a single component.
I am using dc.js for showing some of the charts on my dashboard. What I am looking for is to handle each chart's click event (e.g. bar chart click event, pie chart click event and mouse up event for ranged charts etc.) and save the history of clicked charts in the database. This way user will be able to see the clicks user has made for any of the chart after login.
I have checked dc.js for click events but I am not getting that properly.
Can anybody help me? Any help would be appreciated.
It might be easier, and more helpful, to watch the 'filtered' event:
chart.on('filtered.monitor', function(chart, filter) {
// report the filter applied
});
I say easier, because you don't have to worry about watching different events for different charts. More helpful, because 'filtered' shows you the result of clicking without further processing, so you can show what was actually looked at rather than just what was clicked.
.monitor in the example above is an event namespace. You can use whatever string you want there, but do use some namespace to avoid stepping on other watchers of the same event.
If you really want click events, you can override chart.onClick by assigning to it and calling the old handler (yuck), or you can use e.g.
chart.selectAll('rect.bar').on('click.monitor', ...)
But now you'll have to look at the source to figure out what to select in each chart. And the namespace here is essential because you don't want to interfere with internal event processing.
I have to create a database for a one off work project and everyone has decided to use access as it is already installed on every machine. Now I'm new to access and new to databases in general so this has been a bit of a struggle. Still I'm getting there and have managed to make all the tables, set up relationships between them and create basically all the forms, but seem to have fallen at the last hurdle.
We have lots of different sites, each of which has lots of different rooms. What I am struggling with is the form for rooms. This is loaded from the site form. So site A will bring up a form with all the rooms in site A. The form can be loaded in read only, modify, or new record modes.
The problem is with the navigation buttons at the bottom. If you click new record using the navigation button then access creates a new record, but it loses the FK reference to the previous site. I have put a 'sort of' fix on this by making the FK on the form a combobox, so it can be corrected, but there are 40 sites so it isn't very elegant and isn't the behaviour anyone would expect.
To try and get around it I decided to try and build my own version of the access navigation controls, and eventually (with a lot of help from previous questions on stackoverflow) I succeeded and at the bottom of the form you can go to the first record, previous record, next record, last record, add a new record (keeping the FK reference) and even search through the loaded records in the recordset.
However all that becomes useless the moment I switch off the navigation controls. As soon as I set that to off for whatever reason access only loads the first record in the record set. So if site A has 10 rooms you only see room 1, and the controls I made (which work perfectly with navigation controls on) stop working, and furthermore the textbox I set up to mimic the '1 of 10' record number indicator changes to '1 of 1' making it clear that none of the other records are accessible.
This is really frustrating as it means I can only use my custom navigation controls by keeping Access's turned on. I don't want the access one turned on as it creates problems every time a new record is created.
So, after that long introduction, my question is: Why is access only loading the first record with navigation controls off, is there a way to stop this happening, and if not, can I just disable the new record bit of the navigation control?
Any help here would be greatly appreciated. I am sure it is a very simple thing, but googling has turned up nothing, and actually from what I have read I'm not even sure disabling navigation controls normally does this which makes the whole thing all the more depressing as this is literally the only form I don't want them on.
Thanks,
Dean
If your only reason to add your own navigation controls was that you couldn't have the FK in you rooms form filled, I would keep the access navigation controls and set the FK in the Form_BeforeInsert() trigger of your rooms forms with something like this:
Private Sub Form_BeforeInsert(Cancel As Integer)
Me!FK = forms!Sites!PK
End Sub
If you would like to keep your own navigation controls, it would be helpful, to see your code to be able to answer your question.
I'm having a sort out of my (Delphi) applications and I been visiting the floating form size and location persistence which seems to be increasingly important with larger screen real-estate and multi-monitors. Clearly it is often desireable to have a user's form reopen in the same place as they closed it, but maybe not always, for example a modal dialog might justify opening bang in front of the users vision, i.e on the primary monitor center screen. There seems to be little out there on the 'net about this and commercial applications seem inconsistent especially regarding multiple monitors. So, a few (probably contravertial!) rules to get us started...
Non-modal forms should always reopen at the size and location of closure.
Modal forms (i.e with OK/cancel, Yes/No buttons) should reopen at the
previous size (if sizeable), but inthe center of the monitor on which the application resides.
An information message box should open in the center of the monitor on which the application resides.
A warning or error dialog should open in the center of the primary monitor.
Thanks in advance,
Brian
"Non-modal forms should always reopen at the size and location of closure."
They must have a default position and size when they first open. Do you have
any rules about this?
I would add the qualifier: If the screen resolution/monitor count is
different from the last time this form was opened, then it reverts to default
position. So no inaccessible forms restored 400 pixels to the right and below
the screen area.
"A warning or error dialog should open in the centre of the primary monitor."
I don't understand why you move the messagebox from 'monitor where the app
resides' (henceforth MWTAR) to the primary monitor. You know the punter is
looking at the MWTAR; after all he has just done something 'bad'. Why are you
changing monitors now you have something important to say?
(After all, if it is an error dialog containing useful diagnostics, he won't
read it anyway. I don't see the need to hide it from him.)
A further thought. One problem with error modal dialogs is that, wherever they pop up, the user may hit 'Enter' accidentally while typing something else and dismiss it. I know I do this quite often.
One trick I have seen to overcome this is to disable the Ok button when the dialog is first displayed. There is a 3 second timer in the dialog which counts down, displaying the time remaining in a small label attached to the button. So the punter knows he will be able to dismiss the thing soon.
Obviously this must be used very, very sparingly, and only on the rarest and most important of dialogs. But it struck me as quite clever. Perhaps all that needs doing is to make Ok the default button after three seconds.
A dialog should never open in the center of the monitor. Consider one of the 30" monitors with 2560 x 1600 pixels resolution - using an application maximized on one of these monitors makes sense only in very specific cases. If an application form resides in one of the corners of that huge screen area then the user would need to move the mouse cursor from its current location to the center of the screen, and back after dismissing the dialog. Also, with a normal viewing distance it's probably impossible to have all of that screen in view at the same time, so center of the active window will be more "in front of the users vision" than the screen center. Any dialog that doesn't remember its position should open centered on its parent window. Exceptions should be made for dialogs that are bigger than their parent window (where it makes sense to leave a bit of the parent visible, which makes it more obvious for the user what's going on), and property pages that should appear near the objects they apply to.
I would also think about saving screen positions in percent of the screen area, not in pixels. This way using a laptop with and without a large external screen will always make optimum use of the screen area - using absolute coordinates will either have portions of the screen unused, or windows moved outside of the visible area.
Depending on the platform, when the application does not have focus when throwing up an alert it should avoid taking focus. Too easy for a user typing to dismiss the alert without any chance to read it.
E.g. on Windows make use of the ability to flash a task bar button.
I have a view with a toolbar - each button on the toolbar represents a new message the user is composing. It took me several work days to figure out how to handle the view switching, etc.. but now that I have that all figured out, I have run into a bit of a UI-snafu.
When I have over 11 buttons (I know, a user should really SEND the first 10 before creating an 11th, but I am trying to be thorough) the buttons run off the end of the screen. There is no indicator (aside from the half-button you can see), that there are additional button(s) that can be pressed.
Has anyone run into a situation like this before, and how have you handled it?
My initial thought is when there are more than (lets say) 8 buttons, I programmatically make the first and last buttons "<" and ">" buttons that will slide the buttons down, by removing and adding buttons to my [toolbar items].
Any thoughts?
Instead of creating a new type of UI for the iPhone (which Apple may or may not accept) it would probably be best if you just told the user that he/she has reached the limit and will have to send a message before they can create a new one. Like Safari does when you try to open a 10th webpage.
I think Kane is probably correct, but what you're trying to do sounds a lot like a scrollable tab bar. Three20 offers a class that handles this, or you could implement it yourself. There's no provision for this in the OS (I think the UI guys would probably strongly object if you said you were trying to put 10 buttons down there, let alone MORE than 10.)