Using the Domino/Notes API, when importing DXL design elements (for example a LotusScript agent), you have the option to either compile LotusScript code at the time of import, with DXLImporter.setCompileLotusScript(boolean flag), or leave the code uncompiled. If you leave the code uncompiled, then Domino will compile the code before first use. This is all fine with LotusScript.
Reading the API, I see no option for Java code. How can you compile Java code for use after importing from DXL programmatically?
(The question is not how you do it manually (like open every Java design element and save it to force compilation) but how it can be done programmatically)
You're going to need to do something along the lines of what the ODP to NSF compiler does https://frostillic.us/blog/thread.xsp?thread=NSF+ODP+Tooling. For obvious reasons (OSGi dependencies, Java library accessibility, builder processes etc) it's not a trivial task.
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.
In Lotuscript you can manipulate design elements - create them, change them, rename them, etc.
Are you able to do the same thing for Xpages and custom controls design elements?
====================================================================
My question should have been clearer. What I want to accomplish is to copy an existing cc and give it a new name, programatically. The app will then close and reopen (or refresh or get rebuilt) so that the app can "see" the new cc. If I copy the cc it will only have one field on it. I will add custom code later. I could just create a new cc with no code in it, that would work too.
I am not familiar with the DXL exporter but I can research it. Using that can I just export the design of the cc to an XML file in a temp directory, use the transform to change the name, and then import the control?
I think the XPage or Custom Control design elements are probably under MISC_CODE or MISC_FORMAT design elements in a NoteCollection.
However, accessing that design element is the easy part. Doing a create / rename / change etc is a much bigger task.
Remember that the XPage or Custom Control XML file is only a starting point:
XPages and Custom Controls also have a .xsp.metadata file, as you'll see with source control.
Custom Controls will also have (and need) a .xsp-config file.
There are corresponding .java files for every XPage and Custom Control in the Local source folder. They're created by a builder based on parsing the XML. I don't think you'll be able to create those programmatically. I'm not sure of the impact of renaming them.
For Custom Controls, even if you can rename the .java file, it's referenced in the .java files of relevant XPages. Updating those is goiong to be a significant task.
The XPages runtime doesn't even use those .java files. Instead it uses the .class files in WebContent\WEB-INF (you need to use Project Explorer view and modify the filter to see those files). This is compiled byte code, so you won't be able to update the .class files for XPages containing renamed Custom Controls, as far as I know.
Even if you can rename the .class files, the XPages runtime almost certainly won't use them until either a Clean (which will overwrite anything you've done) or an HTTP restart. As far as I can tell they're cached.
Depending on your use cases, it's possible not all these points will be an issue, e.g. if you're modifying the XML files and building with headless designer.
I suspect this is why nothing was added to the NoteCollection object or a specific NotesXPage / NotesCustomControl API class added.
In Lotuscript you can manipulate design elements - create them, change them, rename them, etc.
This is only partially true. There is a LS API to create/alter views and outlines. Good luck with other design elements - although they're standard "notes", so you can access their items, in most cases you won't compile them and there will be some problems with signatures (real experience with TeamStudio CIAO).
Your question has two points of view - do you want to alter design elements in design process or alter running application?
To help a designer you can go the way of Eclipse extensions and enrich tools in IBM Designer to help developer. Something like TeamStudio Designer. In this case you need to look for source design elements, mentioned by Paul.
To enrich application you don't need to alter source design elements. IBM Designer transforms XML in source code to a Java code (JSF framework) - so you can generate your Java code from anything you wish. Take a look inside Local\xsp folder of NSF in Package explorer. You will find Java sources made from your XPages and Custom Controls. So if you don't need to work with design elements, go for Java components - they can be built on the fly.
And of course, there is always the option of DXL framework - so you can clone/alter design of the application through XML transformations. Good starting point: http://www-10.lotus.com/ldd/ddwiki.nsf/dx/ls-design-programming.htm
I work on a project that uses unmanaged visual C++ and a smattering of C#. We are trying to come up with a way to document our project, both the API reference, as well as some additional conceptual documents. Ideally, all of the documentation would live together in a .chm file that we could distribute with our product.
I was already familiar with Doxygen, as a long time C++ developer. Someone suggested that I look into Sandcastle as well, but I've run into a few snags.
From a number of other sources, including other posts on this site, it's well known that sandcastle does not support unmanaged C++. I did find a post that seems to indicate that you can still cram the C++ documentation into sandcastle, by adding the API reference as conceptual topics.
Using Visual Studio 2010, you can turn on the /doc option in the project settings for your unmanaged C++ project. This produces .XDC files which studio then compiles into an .xml file that goes along with your lib/dll/exe. Where I am stuck is that is unclear what exactly you can do with this xml file. Some pages I've found online suggest that you may be able to use this file for intellisense, but I've never seen that work in unmanaged C++. I was hopeful that I might be able to use this .xml file in Sandcastle Help File Builder somehow, but I can't find any examples of how that's done online, and every attempt I've made with SHFB has failed. It seems to only want MAML or HTML files if I want to add an existing conceptual help file.
So my question:
Is there a way to get my /doc generated .xml file into my SHFB help solution?
If not, what is the point of the /doc option for unmanaged C++?
Is there some kind of transformation I can do on my /doc generated .xml file to produce HTML or MAML which I could then import via SHFB?
Can this work, or should I just go back to Doxygen?
In theory, Sandcastle could be used to document unmanaged code but it would require a tool to produce the equivalent reflection data file that is currently produced by the MRefBuilder.exe tool for managed code assemblies. So far, nobody has done that to my knowledge.
I can't comment on the lack of IntelliSense for unmanged C++ since I don't use it anymore. At a guess, /doc is probably there for the managed code output assuming the same compiler is used but with a few extra command line options.
Using XSL to transform the XML comments to MAML is a possibility but, again, it's an option I'm not aware of anyone pursuing. My guess is that most opt to use Doxygen in this case since it's an established solution.
Eric
I have a similar situation. I need XML documentation in my C++/CLI bindings so .NET code can see them with Intellisense. But FYI, Visual Studio 2010 doesn't support XML documentation in native code:
https://msdn.microsoft.com/en-us/library/ms177226(v=vs.100).aspx
Visual Studio 2010
In Visual C++, you can add XML
documentation (triple-slash) comments to your source code and instruct
the compiler to output them to an .xml file. This file can then be
input to a process that creates documentation for the classes in your
code. The IDE for Visual C++ in this version does not support XML
comments in Intellisense.
That limitation was removed in Visual Studio 2013. However, it's still an annoying ecosystem to work with if you use templates in the native code (e.g. Boost libraries):
In the current release, code comments are not processed on templates or anything containing a template type (for example, a function taking a parameter as a template). Adding such comments will result in undefined behavior.
I found your question while searching for a way to temporarily disable the XML comment parser with a #pragma or #define when including such libraries.
I have noticed that lately our xpages application build/compilation time has gone drastically up. It can even take almost whole minute to clean application.
It is quite complex app with some controls (custom controls and java controls) and a lot of legacy code (js, ls, java), but similar app build in pure ecplise with the same amout of java code (which is the only part of this app that changes) cleans in less than 3 seconds ...
I have done a bit of research with rcp debug console and noticed that while cleaning there is some insane traffic that sums to 15000 transactions (and this database has only like 300 design elements that contains code at all!)
The log looks like this repeated over and over again:
...
[1240:0007-03E0] (13586-124 [14561]) OPEN_NOTE(REPC12579BB:0033C2FE-NT00003052,00400000): 0 ms. [48+17446=17494]
[1240:0007-03E0] (13587-124 [14562]) OPEN_NOTE(REPC12579BB:0033C2FE-NT00006C12,00400000): 1 ms. [48+32118=32166]
So my question is:
Does this mean that xpages builder is really badly written or maybe I do not know something?
Are you doing Project - Build or Project - Build All. If the latter and you have multiple NSFs open, then the build will run for all apps. You can close the apps in Package Explorer.
When you say there are 300 design elements, is that the number you see in the Applications Navigator? Bear in mind that's just a drop in the ocean of the actual files being built. Package Explorer will show there are additional Java and xsp-config files for each XPage and Custom Control. These are the Java classes compiled down from the XML markup you see in the XPages and Custom Control design elements. But this is not all that gets built. The server or local database cannot run .java files. It needs to run .class files compiled for the relevant platform. In addition, there are other .class files that need incorporating into the application at compile time, which can be seen by selecting Project - Properties in the Package Explorer view. If you have localization, there are still more files for each language for each XPage / Custom Control. And of course there are files like xsp.properties, an activator .java file and .class file.
The XPage builder may seem badly written because these files need creating. But it is actually very clever, because we don't need to write Java and we don't need to define all the relevant Java files the application is dependent on. We don't need to create a new XSPInput or whatever the Java classes are for the various controls. We can just drag and drop, set the properties from pretty panels which give us drop-downs or Boolean selectors etc. Without those the build time for the app after each save would be quicker, but the development time would be slower.
Its appears after all that there is a solution to build time problem - its the new Domino Designer 9. After upgrading to public beta version the build times dropped drastically (to just few seconds)!
I am using a UI component from J2ME Polish. I found a simple bug in the code, and want to quickly fix it but cannot find any build scripts in the download package, although source-code is included.
The problem cannot be solved by extending the class as it involves members with private access.
How should I go about fixing it? Should I simply compile the class in question with Javac or should try to locate build script in their repository?
There is no binary code for J2MEPolish UI library, because these classes are also preprocessed during your application compilation. This is why there is also no build script for J2MEPolish UI part - the resulting binary, if it compiles, would not make any sense :)
If you are using this UI class directly (there is no Polish magic involved) I would suggest to copy it into your own project, make the changes there and you should be just fine.
But there is a small issue. I'm not 100% sure, but Polish build process should be as follows: first your classes are preprocessed and then Polish classes will be preprocessed. If the UI component, that you copied into your project, will stay in the same java package, it could happen that your changes will be overwritten by buggy Polish implementation. You can check it by running the application or looking at the final java code in build directory.
If the overwriting problem happens, then you have two options - move UI class in your project into different package (I'm 99% sure this should be fine if you use it directly) or you need to modify Polish build process, so that it would preprocess Polish classes first and you could overwrite changes done by it.
/JaanusSiim
I know this question has been answered and accepted but an easier method would be to used their built in property (for any one coming here via the magic search engines)
polish.client.source=/projecthome/j2me-polish-source
which is simply a copy of their sources packaged with the installer. You can copy this into your own source tree and thus have version history of your changes.
While JaanusSiim's method might work I would not recommend it as it becomes confusing having de.enough.** packages in your own source tree I normally create a src for my personal source and a src-j2mepolish for their source files this was it is VERY explicit what I have added to the standard versions.