How do I stop MetaTrader Terminal 4 offline chart from updating the price on its own?
I want to update the price on my own because of the difference in timezone with my broker. I have checked all the properties and the MQL4 forum. No luck.
For truly offline-charts, there is a way
While regular charts process an independent event-flow, received from MT4-Server, there is a change for retaining your own control over TOHLCV-data records -- including the TimeZone shifts, synthetic Bar(s) additions and other adaptations, as needed.
You may create your own, transformed, TOHLCV-history and import these records via F2 facility, called in MT4 a History Centre.
How to avoid a live-quote-stream updates in MetaTrader Terminal 4
The simplest ever way is not to login to any Trading Server. This will avoid unwanted updates from reaching your local anFxQuoteStreamPROCESSOR.
There used to be a way, how to inject fake QuoteStreamDATA into a local MT4, however this enters a gray, if not black zone, as MetaQuotes, Inc., postulated the Server/Terminal protocol to be a protected IP and any attempt to reverse-engineer they consider an unlawfull violation of their rights and could cause legal consequences, so be carefull on stepping there. Anyway, a doable approach with an explicit risk warning being presented above.
Can't be done. Quotes get fed in from mt4 and get "evented" into the metatrader.
Related
I'm developing a software that displays information in a DBGrid via a TSimpleDataSet (dbExpress components)
The software in question is used on 2 different computers by 2 different people.
They both view and edit the same information at different times.
I'm trying to figure out a way to automatically update the DBGrid (or rather, the DataSet, right?) on Computer B once Computer A makes a change to a row (edits something/whatever) and vice-versa.
Currently I've set up a TButton named Refresh that once clicked executes the following code:
procedure TForm2.actRefreshDataExecute(Sender: TObject);
begin
dbmodule.somenameDataSet.MergeChangeLog;
dbmodule.somenameDataSet.ApplyUpdates(-1);
dbmodule.somenameDataSet.Refresh;
dbmodule.somename1DataSet.MergeChangeLog;
dbmodule.somename1DataSet.ApplyUpdates(-1);
dbmodule.somename1DataSet.Refresh;
dbmodule.somename2DataSet.MergeChangeLog;
dbmodule.somename2DataSet.ApplyUpdates(-1);
dbmodule.somename2DataSet.Refresh;
dbmodule.somename3DataSet.MergeChangeLog;
dbmodule.somename3DataSet.ApplyUpdates(-1);
dbmodule.somename3DataSet.Refresh;
end;
This is fine and works as intended, once clicked.
I'd like an auto update feature for this, for example when Computer A edits information in a row, Computer B's DBGrid should update it's display accordingly, without the need to click the refresh button.
I figured I would use a TTimer and set it at a specific interval, on both software on both PC's.
My actual question is:
Is there a better way than a TTimer for this? If so, please elaborate.
Also, if the TTimer route is the way to go any further info you might find useful to state would be appreciated (pro's and con's and so on)
I'm using Rad Studio 10 Seattle and dbExpress components, the datasets connect to a MySQL database on my hosting where my website is.
Thanks!
Well, Ken White and Sertac Akyuz are certainly correct that using a server-originated notification to determine when to refresh your local dataset is preferable to continually re-reading all the data you are using from the server.
The problem AFAIK is that there is no Emba-supplied notification system which works with MySql. See this list of databases supported by FireDAC's Database Alerts:
http://docwiki.embarcadero.com/RADStudio/XE8/en/Database_Alerts_(FireDAC)
and note that it does not list MySql.
Luckily, I think there is a work-around which should be viable for a v. small system like yours currently is. As I understand it, you and your colleague's PCs are on a LAN and the MySql Server is outside your LAN and on the internet. In that situation, it doesn't need a round trip to the server for one of you to get a notification that the other has changed something in the database. Using an analogy akin to Ken's, you can, as it were, lean over the desk and say to your colleague "Hey, I've changed something, so you need to refresh your data."
A very low-tech way of implementing that would be to have somewhere on your LAN a resource that both of you can easily get at, which you can update when you make a change to the DB that means that the other of you should update your data from the server. One way to do that is to have a small, shared datafile with a number of records in it, one per server db table, which has some sort of timestamp or version-ID number which gets updated when you update the corresponding server table. Then, you can periodically check (poll) this datafile to see whether a given table has changed since you last checked; obviously, if it has, you then re-read the data you want from it from the server and update your local record of the info you read from the shared file.
You can update the shared file using handlers for the events of your Delphi client-side datasets.
There are a number of variations on this theme that I'm sure will be apparent to you; the implementational details really don't matter.
To update the shared file I'm talking about, you will need to lock it while writing to it. This answer:
How do I get the handle for locking a file in Delphi?
will show you how to do that.
Of course, the shared local resource doesn't have to be a data file. One alternative would be to use a Microsoft Message Queue service, which is sometimes used for this kind of thing, but has a steeper learning curve than a shared data file.
By the way, this kind of thing is far easier to do (at least on a small scale like you have) if you use 3-tier database access (e.g. using datasnap).
In a three tier system, only the middle tier (a Delphi datasnap server which you write, but it's not that hard) talks to the server, and the clients only talk to the middle tier. This makes it easy for the middle tier server to notify the other client(s) when one of them changes the db data.
The three-tier arrangement also helps minimise the security problems with accessing a database server via the internet, because you only need one secure connection to the server, not one per client. But that's straying a bit far from your immediate problem.
I hope all this is clear, if not, ask.
Just use a timer and make it refresh the dataset every 5 min. No big deal.
If the usage is not frequent then you can set it to fire every 10 or 15 min.
There is nothing wrong with the timer if it set on longer intervals.
Today's broadband connection's can easily handle the traffic so can Access.
If the table is not huge of course.
On each new bar/tick, my variable is re-initialed, I am trying to execute a trade once per signal, the problem is that once TP is achieved, if same trends continues, it triggers another trade. I am thinking to store variable in Text file. So just wondering what would the best way to handle such variable. Sorry I don't have code.
MT4 Global Variable objects
While MT4 supports somehow ghost-alike semi-persistent objects called "Global Variables", that can survive between MT4 Terminal re-runs for about several weeks, these ghosts are rather complicated to be used for your sketched purposes.
GlobalVariableCheck()
GlobalVariableSet()
GlobalVariableSetOnCondition()
GlobalVariableGet()
FileSystem Text-File
While doable, this ought be a last resort only option, as this is the slowest and the least manageable part, once running several units, several tens, several hundreds of MT4 Terminal instances in the same environment, the risk of fileIO collisions is clearly visible.
Solution?
Try to create & maintain a singleton-pattern to avoid multiple re-entries into a trend you have already put one trade into.
Try to setup also a clear definition for trend reversals, which stop / reset the singleton-pattern once a new trend was formed.
I run a successful Minecraft Tekkit modded server with computer craft on it.
I'm fairly new to lua and only know the basics, I'm trying to make a menu with pages to display the banned items list and rules list on. I've made a program with arrows that's optimized for advanced computers and monitors.
The code runs properly on my advanced computer but doesn't run on the monitor, when it shows and someone clicks the arrows it doesn't work either.
I just started using stack so I'm not sure on what to do, if you need any info please ask for it :)
The code: http://pastebin.com/gVtPeBCE
By the way I already tried using Mon.write and Mon = peripheral.wrap("top")
For those who don't have tekkit here is a computercraft emulator: https://goo.gl/J0dPq0
I'm sorry to inform you that I haven't read through all of your code. But judging based on your description, I would say that it's likely one of three issues, not including incorrect syntax as a possibility.
Note: Your question is exclusively asking about the programs ability to run on a monitor while the emulator you link to only provides the desktop ComputerCraft computers.
Peripheral
Although you already stated:
By the way I already tried using Mon.write and Mon = peripheral.wrap("top")
I would like to clarify that you can, as a way to simplify the code transition, set the peripheral function table equal to the term variable. For example: term = peripheral.wrap(string_side).
Note: When you use this method, you shouldn't execute the program with the command:
> monitor side program.
You should instead run it as a normal program with no special treatment.
I.e. > program.
Incorrect Mouse Event Detection
Simply put, when using a monitor, you're not supposed to pull for a mouse_click event. You have to pull for a monitor_touch event instead.
while true do
type, side, x, y = os.pullEvent()
if type == "monitor_touch" then
print("Monitor '"..side.."' has been pressed at "..x..", "..y.."!")
end
end
Monitor Size
This just simply means that the program you're trying to execute on the monitor takes up to much space and is therefore unusable when displayed on that size of monitor.
Suggestion: Either update your code for the monitor size or build the monitor to fit the program.
Please remember that all of these ideas might not answer your question, as the code you have provided to look over is too large and I haven't been able to find the time to experiment with it. Therefore, these are only general suggestions.
if i had to guess, it's because term is short for terminal and will auto work with computers so if you set term to be the monitor at the top of the file it should work correctly.
term = peripheral.wrap("SIDE OF MONITOR")
Put that at the top of your code and it should work. but this what i think it is after taking a look at your code (also its not that long of a code sample...)
How can I make a 30-day trial for my application? I need to allow users to use an application only 30 days. How to count these days?
I keep the first and the last date in registry. But if to change a system time - no protection will be. I need to count these 30 days.
You could probably come up with a system that requires an internet connection, but without something that the user can't tamper with, I don't see a solution.
Any solutions that rely on an untrusted element (an element of the protection that is under the user's control) is critically weak.
The simplest way I can think of to protect against the user moving the clock back is to limit the total number of launches.
However, attempts to limit the number of launches requires persistence -- saving data to the disk, perhaps encrypting and storing a modified version of your activation data file -
Imagine that you count one of the 30 days as "used up" once the app has been launched, on a unique occasion, even when the same date is re-used. In order to avoid using up more than 1 "activation time day" when launched, the user must allow your software to re-save its activation file each time it runs.
To block that approach, the user needs only to keep the apparent date from changing, plus they must either prevent you from storing anything to disk; or they can simply track and record your changes and reverse them out, either using a monitoring process, or using VMWare snapshots. About VMWare snapshots, you can do nothing. The virtual machine's disk is not under your control.
You can protect your app of users setting the clock back simply by storing in the registry the date of last execution.
Each time the app is started you need to do the following:
Check current date (as reported by the system clock) against the stored last execution date and, if current date is earlier than the last execution one, consider that the trial period has expired (or whatever you prefer).
If the previous check is ok, save the current date in the registry and continue execution.
As WarrenP says, any technique storing information locally can be easily circumvented using VMware snapshots.
And anyone, including those who check via internet, can be skipped via assembler level hacking.
Here's a discussion on Shareware trial enforcement with Delphi:
Best Shareware lock for Delphi Win32
Along with discussions on various 3rd-party solutions, techniques for DIY, etc..
IMO, DIY is feasible if your app produces data that the user will want to keep around, then you can simply embed a copy of the usage/day counter in the database in such a way that they can't wipe it without destroying their data. I also like watermarking (printing "trial" on reports, etc..), escalating nag severity, but I do not recommend or condone "drop-dead" crippling until WAY past the expiration data. I also like to measure "days of actual use", instead of using a calendar.
Registry manipulation works, and many of the 3rd-party protectors use it. But you need to be stealthy, and keep backups in several locations simultaneously.
You should also consider having separate trial and registered versions. But also consider that pirates will buy the registered version with a stolen card, and put it on Rapidshare, BitTorrent, etc..
Also note that elaborate defenses lead to support headaches. Sometimes PCs crash and the clock gets set backwards. They install new harware. PCs get rebuilt, restored from backup, etc.. If a user is running a debugger, he may be a software developer, not a pirate. If your app looks like it has been patched, it may be an overly-aggressive antivirus. And at any time, a shoddy patch for Windows may cause your program to think that it's being attacked, hacked, or reverse-engineered. You have been warned...
Encrypt a date and store it in registry the best way to do it is that date to be stored by the installer itself and if the date doesn't exist the application should quit.
There is an open source project (which was a commercial product before):
TurboPower OnGuard is a library to create demo versions of your Borland Delphi & C++Builder applications. Create demo versions that are time-limited, feature-limited, limited to a certain number of uses, or limited to a certain # of concurrent network users.
I have not checked which Delphi versions are supported.
For this kind of "protection" and some others, I have used TmxProtector (open source) from MaxComponents in the past with good results. From the link provided:
The TmxProtector is a software protection component. It was designed
for quick implementation of application protection functions. You can
create time-trial and password protected applications. You can set the
maximum number of execution, and it can work with registration keys as
well.
This compoment uses very simple encryption to store the expiration date in the registry and it provides some simple detection for tampering on the system date.
It sounds like you need to store the date the last registry entry was written. Then inside your program, test if the current date is less than the date last registry entry was made. If true display a message that the trial period has expired and the program must be purchased.
Here are some ideas on how to deal with clock changes during the trial period:
Save both the date of first and the date of the last program start. If the date of the last program start is greater than the current date, then the user has moved the clock back. I simply increase a day and save the new date as the date of last start. You can of course decide to just end the trial.
To try to defeat trial bypass programs (RunAsDate for example) which run your application by setting the date and time to a specific value, you can instead of getting the date via the usual Delphi way (Date, Now), get, for example, the last modification date of NTUSER.DAT.
Save your trial data on two separate locations, either two registry locations, or file and registry. This way even if the user deletes one of the trial data locations, you'll still have a backup one to use.
If you keep your trial info in registry, the registry could be deleted by the user. Evey one expects to find the registration info there.
There is one place where the user might not think to look into: your own app (EXE file). Put an ANSI string constant (MUST by ansi/ascii or other 1 byte string, static array, etc) into your program, like 'xyxyxyxyxyxy'. Compile your app. Open your complied app with a hex editor. Search for that string. Now your program could use that area to store the trial info into itself.
Use this method in conjunction with others: store your info in registry also, on disk, etc.
Anyway, the best would be to get the registration info from your server.
The big drawback: 1. The server must be ALWAYS online! 2. The user must be connected to internet (when it uses your app).
Also use a Delphi license management library to help you encrypt the license info and generate a string-based key that you can send to your customers upon registration.
Anyway, whatever you send to your server needs to be based on the hardware fingerprint of that computer. Otherwise your license key will leak out on some warez website and everyone will be able to use that key. But if the key is hardware-based it would be useless if it is leaked on Internet.
Just remember: don't over do it! There is no such thing as unbreakable software protection. Microsoft could not do it!
As the thread pointed to mentioned, I encourage you to look into WinLicense: http://www.oreans.com.
I've been using it for quite some time and it handles trial periods quite well. It also handles licensing, customer lists, etc.
Tom
I'm looking to add a 14-Day trial limit to my software. The program has been written in Delphi 7.
Any help would be much appreciated.
You could try Turbopower OnGuard. This is now opensource.
http://sourceforge.net/projects/tponguard/
There are several tricks you can use, but none of them 100% fail save.
You can use some kind of licensing mechanism.
You can store the setup time somewhere hidden in the registry.
You can store the setup time in a file (possibly an executable file or dll).
You can store the IP address in a central database and check each time if the 14 days are passed (you need a internet connection for that).
You can create a file (for example a dll) dynamically on your server and have the installer retreive that file. (Be sure to log the IP so a second attempt will not be possible).
But I think the best way, is to give trial versions with limited functionality. For example: No printing, no save of project, or only small projects can be saved.
That way you avoid the hassle and possible clients can take the time to evaluate your project.
EDIT: If you build a mechanism to check against roling back the clock. Be sure to build in a margin, else the program will be locked if you travel back to an other timezone. Or put the clock back in wintertime. I think a margin of 25 hour will cover everything. (And to be at the save side, you can build in a limit else, the user can roll back the time each day.).
But the best way to keep paying customers, is giving good support. I discontinue products if the service is bad.
One of the things you need to guard against with a time-limited application is users' rolling their calendar back so the application still works. One way around this is to store in your hidden registry place (or wherever) a timestamp whenever the application is started up. If the current date/time is ever earlier than the last timestamp recorded by your app, that means the user has rolled the calendar back and you should disable the application.
Time-limitation is a real pain, though, both for the programmer and the user. It's also not a great marketing idea: why go to the trouble of distributing promotional material (which is what your trial version is) that has an expiration date? It would be like a company mailing out advertisements on paper designed to disintegrate after two weeks.
If your trial version is functionally crippled instead, you might still get sales out of it even months or years later.
You can find the similar question here.
On general note i find time restriction much more useful than functionality restriction. As i explained in the comment to Gamecat post
something to be aware of when performing any of these checks. That the date is never GREATER than 14 days from the date you entered in either direction. A common method around most of these types of limits is to set the date a few years in advance, install and run your software, then set the date back to the current time. If you are hard coded to die 14 days from the original start date, then the user has a few years to try your software. Checking the other direction also gives the user at most 28 days.
I have used Armadillo, Asprotect and Winlicense. Both Armadillo and Asprotect have had serious problems, such as being considered viruses/trojans by some AVs, incompatibility problems, etc.
I haven't used Winlicense enough to have much of an opinion, but support is pretty great.
Obviously both are more complete solutions than what you are asking for - they include protection, licensing, keys, etc.
As mentioned by others, sometimes limiting a feature or adding a watermark is the best option. I've added a watermark to one of my programs (STGThumb) and sales went up about 400%...
I would recommend making a trial serial number with timestamp and force user to enter it into software when its installed. You can even automate it by calling server side page after setup is done.
Timestamp in trial serial key allows you to extend their trial if needed.
In addition you can count backwards to avoid user from changing year when installing:
e.g. if you have 14 days trial generated at 15.11.2008 (server time), you can check that locate date must be greater than 1.11.2008 or less than 24.11.2008 always when serial is used or entered.
You can use a professional tool as SoftwareShield.
I use it in our apps and it provides several licence's models, including timelimited demo.
I created my own key generater (separate program for creating keys). The key values are stored in a binary file with the same name as my program, just a different ext. Example: myprogram.key
I store:
Name
Email
RegType (REG, TRIAL)
RegDate
FirstRun (0 OR 1)
The program looks for the file. If it is not there, it throws a message to the user and closes. The key file generator writes the values in encrypted strings which are then written using the built in stream routines.
I create a TRIAL Key that i distribute with the program. If someone registers, i then create them an official REG key.
Anway, if they are running my program, it first looks for the key file. if found, it checks the reg type, if its a regitered version, then the program loads, and the registration info is displayed. I also store a regdate, which i compare with the day the program runs and - if the regdate is greater than or equal to todays date, the user get sprompted to re-register.
If it finds that the key file stores a RegType of TRIAL, then the date they first ran it is stored in the keyfile, and the flag first run is set to 1. They can then use it for 14 days. Each time they run the program, the date stored is compared with the running date.
Very simple process to write. Is it fool proof? NO, nothing is! I have had great success with my app. Its not wide known, so there are no hackers lookijng to hack it.
The best would be to get the registration info from your server.
The big drawback: 1. The server must be ALWAYS online! 2. The user must be connected to internet (when it uses your app).
To get you started you can use a Delphi license management library to help you encrypt the license info and generate a string-based key that you can send to your customers upon registration. There are quite few libraries out there.
Anyway, whatever you send to your server needs to be based on the hardware fingerprint of that computer. Otherwise your license key will leak out on some warez website and everyone will be able to use that key. But if the key is hardware-based it would be useless if it is leaked on Internet.
And don't over do it! There is no such thing as unbreakable software protection. If Microsoft could not do it, you will not do it. Concentrate on adding nice features to your app instead of creating a bullet proof protection system (which is not possible).