I'm looking for something similar conceptually to a Windows DLL. As a concrete example, suppose I have a function encrypt that I would like to share across several unrelated projects. If I want to change the implementation ideally I can do so once and every project has access to the new implementation. Is there a mechanism for doing this in Node.js?
Have a look at this document especially the section "Writing a Library"
If you are writing a program that is intended to be used by others,
then the most important thing to specify in your package.json file is
the main module. This is the module that is the entry point to your
program.
and
If you have a lot of JavaScript code, then the custom is to put it in
the ./lib folder in your project.
Specify a main module in your package.json file. This is the module
that your users will load when they do require('your-library'). This
module should ideally expose all of the functionality in your library.
If you want your users to be able to load sub-modules from the "guts"
of your library, then they'll need to specify the full path to them.
That is a lot of work to document! It's better and more future-proof
to simply specify a main module, and then, if necessary, have ways to
dynamically load what they need.
For example, you might have a flip library that is a collection of
widget objects, defined by files in the flip/lib/widgets/*.js files.
Rather than having your users do require('flip/lib/widgets/blerg.js')
to get the blerg widget, it's better to have something like:
require('flip').loadWidget('blerg').
Related
So I'm not sure if this question requires knowledge on the UiPath software in order to be answered or not. I have been developing a lot of Excel macros for my company, and as I get more and more macros, it's harder to manage them.
We have been working on some robots as well within the company, and I notice that the robot has an activity where you can invoke VBA code within an Excel application scope. This activity reads a .vb file with code and invokes whatever method you specify within that file as a macro in the activated Excel application.
Ideally I would want to extract all my VBA code into separate files, and have the robots execute the macros through this activity. This would make it a lot easier to manage the code.
My question is then, if it is somehow possible for me to also extract the modules I've created that contain utility methods that I repeat throughout many macros into a .vb file, and reference this in the other macro files?
I don't know exactly how this activity invokes the code and what restrictions are placed on it. Within Excel, I can store re-usable methods in modules and call on them from other modules. This is what I want replicated on a file level. If there was some way of adding import statements to the top of the code to retrieve methods from other modules, so I could call them within the file.
My worries (and assumption) is that the activity simply reads it as a text file, and just imports it as a macro right into Excel. That if I wanted to reference any modules within my method, the modules would have to already exist in the Excel application.
I could always paste the utility methods into every .vb file, but that sort of defeats the purpose of making it easier to manage.
Is there anything I can do here?
Thanks,
TRS
You definitely can reference external assemblies (.dlls) in UiPath. I haven't done it with VB.Net Projects, but I have done it with C# Projects which is in this case, the same thing.
Please, follow this tutorial: https://www.uipath.com/kb-articles/how-to-include-external-dll
To be able to generate the .dll, you will need to download Visual Studio Community Edition and follow a couple of tutorials on how to compile VB code.
All your VB code will exist in this .dll. This would be your general repository or main library that you would access every time that you need it. As I understand, this is your main goal anyway right? "To access utility methods".
I don't know if inside your macros, you use specific Excel references that could lead to compilation issues. So, be ready to reference everything that you need inside the code.
At the end, to access your custom methods, you would need to reference the .dll and use the activity called: Invoke Method.
I hope this helps.
We are starting a new project using angular2, typescript and gulp. For the time being our application will consist of two subprojects: a components library (which in the future might be spun off into a separate project) and the app using the component library.
The layouts of the project is going to be something along the lines:
/project_root
/component_library
/src
/library
/components
/services
... etc
/application
/src
/app_name
/components
/services
... etc
The components in application will be using components from the library (but not the other way round)
We would like to have clean (non relative) imports in the app components when importing stuff from the library (we want to avoid ugly imports of the sort '../../../component_library/src/library ...etc' plus, what's more important, we want to be able to move the library code to a separate project without the need to update imports.
There are two possible solutions I see (don't like any of them):
Add a gulp task that would watch the component library and on every change copy the file to node_modules in /project_root
Some sort of simlink? so that we can point /project_root/node_modules to /project_root/component_library/src?
I'm afraid the first solution might not work well with IDE autocomplete in the application (first gulp would need to do the compilation/copying then the IDE would need to pick up the change from node_modules - this looks like something that can be really slow)
The second solution feels hacky - it would need to be repeated by everyone who checks out the code from repo.
What would be the best solution here?
what's more important, we want to be able to move the library code to a separate project without the need to update imports.
Ship your component_library with source and add it as a node_module dependency. Then when someone pulls your code they can add a git remote to node_modules/component_library code and work on the two projects seemlessly.
This is the approach I took with ntypescript.
RedHawk generates code for each port but puts all the In_i and Out_i classes into a single pair of files: port_impl.h, port_impl.cpp. Why are these generated classes put into a single file? For most components one must add code into the port method calls to implement the functionality of the component. One can write the functionality into functions in additional source files and simply add calls to the new functions in the port_impl methods to minimize the changes to the generated files, but one must still re-add these calls to each method if one adds additional ports and the port_impl must be regenerated. If each port's generated code were put into separate files, then adding a port would simply generate an additional file and not overwrite an existing file. This would make adding ports much easier.
A better solution is to simply create child classes of the ports which you would like to extend in their own files. Then in the component code, you can delete the pointers to the ports in the constructor (removing the old implementation) and set them to be pointers to your new, extended implementation. I believe the USRP_UHD code has an example of this method.
In more recent versions of REDHAWK, this is the only way to add functionality like this, as all BULKIO port implementations have been moved into the framework and are no longer generated.
I use a firefox addon which makes hidden requests to a website. I already examined the code in all .js .xul and .xpi files. there is only 1 .xpt file (1kb) left where the request must be coded. now i want to open that to examine the code too.
.xpt is afaik a compiled .idl file
Can this be done?
How?
Thanks for your wisdom ;)
An XPT file is a compiled IDL file but it doesn't contain any code - it is merely an interface definition. It defines which properties and methods a component exposes but it doesn't define them - the actual definition of the component has to be in a JavaScript or DLL file. As you aren't mentioning any binary components, the component must be defined in the JavaScript files you already looked at.
In other words: the answer to "Can it be done" is: yes, with sufficient effort. Just looking at the strings contained in the file will already tell you the interfaces defined as well as the property and method names. If you need the parameters/parameter types then you will have to dig deeper. But for your purpose that would be pointless.
How can I share source code between 2 projects in MS Visual Studio 2008 (I'm programming in C++)?
In my case, I have the code for the main game project and now I want to make a simple model editor that uses the game's code, so that whenever I change/add some code in one project it will be updated in the second one.
A common method for doing this, (you'll see it everywhere in open-source packages), is to bundle all the headers into an 'include' folder and all the source into a 'source' folder.
Now in whatever project needs the code, you go to, 'Project Properties->c/c++->General->Additional Include Directories'. Then add the path to the 'include' directory. Finally, add the source/headers to your project, now both projects reference the exact same files, which are in a nice tidy shared location.
You can also build the shared code as a static library or better yet (IMO) a DLL. This involves creating a new project, and learning a little bit about the linker in VS 2008, but really nothing too complicated. This also has the advantage (in the case of a DLL) that the two projects don't re-compile the same code, but rather it is compiled once and used twice.
You can move the required classes into a separate library project and then references this from the second project. Any changes will be automatically picked up.
(I'm not a C++ developer, however the above works for C# projects, I would assume it works for C++ projects too)
You basically have two options:
Create a static library. In this, all the code in the library will be exported and visible to who ever links to this library.
Create a DLL: here, you can define what classes and methods you would like to export and use those.
Lets say you have a class called classA which is defined in classA.h and implemented in classA.cpp and you want to use this same class from two different applications (application B and application C).
Using method 1, you would create a static library by going to file->new win32 project and in the box that pops up, choose application settings and make it a "Static Library". Then in this static library you add both your classA.h and classA.cpp.
To use this static library in application B or C, goto the references and add a reference to the static library project that you just created. then include classA.h in your application (don't forget to set the additional include directories path) and you are good to go.
The approach is very similar for a DLL as well, the difference here would be that you can choose what parts of your code in the DLL are exported (ie visible to outside callers).
From an overall point of view:
With the static library approach, your code will be compiled into both the applications.
With the DLL approach, there will be just one copy of the shared code (in the DLL which will be a separate file) and this will be loaded as required.