I am working within a Metatrader script file and need to call a function within a Boost library. Anyone know if this is possible? If so how do you configure the import?
This is possible.
Check this out: http://docs.mql4.com/basis/preprosessor/import
If you look at most metaquotes mql examples, they import stdlib and stderror . The built in help section in the editor will also have info on how to do this.
Yes, it is really possible.
But all is not as you might imagine.
Of course, it depends on what you want to do, but main idea is to create a DLL and include it to your EA as Dmitry said.
All your functions must be defined like this:
extern "C" __declspec(dllexport) int doSomething(...)
{ ... }
So you may call it from your terminal.
Be careful with c++ types in Metatrader.
In a DLL you can do what you want according to your declaration -- with all data you'll get.
Don't forgot to check your DLL for dependencies (using Dependency Walker) to see what other DLLs your library is using (you must provide them to your Metatrader terminal, copy to terminal.exe location folder, or add folder with your DLLs to your systems path).
Related
I'm trying to setup limeJS, the issue is the Internet connection is a problem. I had closure library, box2d, closure compiler and closure templates downloaded separately as .rar files, but I can't find a guide anywhere to set it up like this, everyone just uses(and with reason!!!) the python bin/lime.py init command to get it working. I managed to figure out(yay!) how to setup box2d and closure library but what about the other two?
My laptop is running 64 bits Windows 7. Any help appreciated
All I need is an advice on directory structure, like where to drop the compiler.jar and soy templates .js files, so that when I run the update/create command it doesn't try to download the compiler or templates like it does right now.
I got it working, after taking a quick look at the lime.py file it told me everything I needed, for example both the SoyJs templates file and the compiler need to be in the /path/to/lime/bin/external folder and for example, the lime.py file was expecting a compiler file named compiler-dateOfLatestCompiler.jar instead of compiler.jar.
In general, If you have LimeJS built up in one machine using Python and all, you can just copy paste the whole package anywhere you want and use it just as ususal.
You don't need network once you have all the files/codes for Lime is downloaded.
Infact, you dont even need python for normal development tasks(Python is required to build your js file once you complete development though)
I tried to build a shared library using wx and STL, and failed in an error of "multiple definition of". Please refer to:
https://code.google.com/p/gppanel/issues/detail?id=7
The declaration of wxPointListNode is not found in the sources. The suspicious lines are like these:
include/mathplot.h:85:WX_DECLARE_LIST(wxPoint, PointList);
include/mathplot.h:87:WX_DEFINE_LIST(PointList);
include/gpLineLayer.h:16:typedef std::deque<mpPointLayer*> mpPointList_t;
What the problem is?
Without the actual code this is just a guess, but I suspect that
include/mathplot.h:87:WX_DEFINE_LIST(PointList);
generates the full definition of PointList, including a non-templated method wxPointListNode::DeleteData. mathplot.h is included by all of the .cpp files (gpPanel.cpp, gpSeries.cpp, and baseData.cpp). Each cpp file is compiled into a .o file, so each has its own definition of DeleteData, and when you try to link the .o files together into lib/libgpPanel.so the linker issues the errors you're reporting.
The definition of the method needs to be in its own cpp file that's compiled and linked in.
All wxWidgets methods with DEFINE in their name expand into a definition of something and a definition can only be used once in a module, so it typically can't appear in a header file (unless you can guarantee that it's included by only a single source file). So just don't put it there.
Moreover, if this is your code, you should avoid using the legacy WX_DECLARE_LIST macro at all and just use std::list<> or std::vector<> instead. Or, if you really want to use only wx (which can only be important if you are targeting some embedded platform without good STL implementation), then use wxVector<>.
I have a project containing a big package "global" of classes which is designed for Web, I need to share these classes with a new mobile project, but when i add them with :
Properties -> Flex Build Path -> Source path -> Add Folder
they start appearing with index [source path] before the package name, and since them Flash Builder start trowing error messages :
"A file found in a source-path must have the same package structure '', as the definition's package, 'global'."
How can i fix this issue ?
As we've discussed in the comments, I think it would be a better approach to compile your "global" classes into a library (.swc).
You were concerned about loading unnecessary classes: when you link to a library as 'merged', only the classes you use are actually compiled into the main application (and any classes they depend on), so there's no need to worry about that.
As a last argument I also think this is a more flexible approach. A compiled library is easier to reuse and version, so the code can more easily be distributed to other developers on your team.
Rename one of the packages with right click->refactor. Than is should work.
If not you can also try to have your two codes available at the same project, and then you can select which to run in Flash Builder, by right-clicking to that .as or .mxml file, and selecting set as ... (or something like that)
I guess if you will include 'src' fonder instead of 'src/global' that problem will disappear.
I want to write a program that outputs a list of libraries that I should link to given source code (or object) files (for C or C++ programs).
In *nix, there are useful tools such as sdl-config and llvm-config. But, I want my program to work on Windows, too.
Usage:
get-library-names -l /path/to/lib a.cpp b.cpp c.cpp d.obj
Then, get-library-names would get a list of function names that are invoked from a.cpp, b.cpp, c.cpp, and d.obj. And, it'll search all library files in /path/to/lib directory and list libraries that are needed to link properly.
Is there such tool already written? Is it not trivial to write a such tool?
How do you find what libraries you should link to?
Thanks.
Yeah, you can create a pkg-config file which will allow you to run 'pkg-config --cflags' to get the compiler flags or 'pkg-config --libs' to get the linker libraries.
http://pkg-config.freedesktop.org/wiki/
If you're on Linux, just try looking into /usr/lib/pkgconfig to find some example .pc files that you can use as models. You can still use pkg-config on Windows as well, but it's not something that comes with it.
I am writing a WIX installer and I have a following requirement:
During installation, I need to pass an absolute path to a file (lets call it A) included in my installer to a COM component, which already exists on the hard drive and is a part of another program. I have already written an appropriate Custom Action which expects a path to the file A. I don't want to include A as a file installed in the Program Files folder and removed during the uninstallation process. Instead, I would like to put A only temporary on the hard drive, call my Custom Action which will cause the COM component to use the content of A, and then remove A from disk. Is there an easy way to accomplish this goal?
I have tried to utilize the Binary Table and store A there, however I don't know how to reference A using absolute path. I know I could put A outside of MSI file but I would like to keep every file installer needs in a single MSI.
Any help would be appreciated.
Deleting a file that MSI installed means that MSI will consider it "broken" and try to auto-repair it if called on to do so. That happens automatically in several cases (e.g., advertised shortcuts and COM registration) so I'd recommend against it. Leave the file there instead -- it's done its job and there's no harm in leaving it there.
I would take this approach.
Install the file "A" into any directory. Run your custom action needed to update the COM component. Then run another custom action or modify the currently written one to remove the file after it is no longer in use. This would leave no trace of the file "A" and if you schedule the custom action to only run during the install you won't have to worry about it on uninstall.