This is a probably a really simple fix, but I'm extremely new to RealBasic and I'm having difficulty finding help.
dim objUnZipIt as new RealUnzip
The error I keep getting is :
There is no class with this name: di objUnZipIt as new RealUnzip
I'm attempting to debug something in a language I don't know, and the original developer is long gone. Where can I find the library? Or possibly make a small alteration to get this running?
Thank you very much.
Edit: Ok, digging through the folders I found a RealZip.dll . Any idea how I can import this ?
The RealZip plugin was provided by a third-party developer whose website has been offline for several years. You can still grab the plugin from the Internet Archive's copy of their site.
Extract the .rbx file into the plugins sub-directory of the REALstudio install directory and restart the IDE. Since this plugin is no longer maintained, there may be issues with using it in a modern version of the IDE (the included demo project works, though, with only a deprecation warning unrelated to the plugin.)
There's also a GZip plugin available on SourceForge (similarly unmaintained) and the commercial MonkeyBread Compression plugin which is actively maintained.
Related
I am new to xamarin and using XLab packages. I can see that Xlab packages are not stable yet however community is strongly supporting. In test
project I have added packages using Nugets. Now I found one issue in camera API of it so, how should I fix it. I have just
library files so, I can see code or fix it immediately.
Should I include the code of it? Because I can't wait for community to fix the issue and get the updated package of it? Yes If I will fix something then
I would love to contribute to open source community.
FYI: I am using PCL approach for development.
Best option would be to fork the GitHub repository and work on the sample application.
You can also get a copy of the source without cloning but then you cannot create a pull request for any code fixes. You can still report any bugs you find but it will be easier to contribute to the project by forking the project.
background
I have designed many tools in the past year or so that is designed to help me program for XPages. These tools include primarily helper java classes, extended logging (making use of OpenLogger and my own stuff), and a few other things that I personally feel I cannot work without. It has been discussed with my employer, and we feel that it might be a good idea to start publishing these items to openNTF. Since these tools are made up of about 3 .nsfs, all designed to use the same java code, key javascript classes, css, and even a custom control or two, I would like to consolidate key items into a plug-in that can be installed at the server and client level. I want to do this consolidation before I even think about publishing any of the work I've done so far. It would just be far too much work to maintain, not just for me, but for potential users. I have not really found any information on how to do such a thing in google searches. I also have to make sure that I am able to make use of the ExtLib libraries, openNTF Domino API, and the Notes API.
my questions
How does one best go about designing such plug-ins? Must a designer
use eclipse, or is this it possible to do this directly in the Notes
Designer?
How does a designer best go about keeping a server and client up to date while designing and updating the plug-in code? Is this why GitHub is often used?
Where is the best place to get material to get started in this direction? I sort of feel lost in the woods, knowing I need to head north, but not having a compass for that first step.
Thank you very much for your input.
In my experience, I found that diving into plug-in development is a huge PITA until you get used to it, but it's definitely worth it overall.
As for whether you can use Designer for plugin development: yes, but you will likely eventually want to not do so. I started out by using Designer for this sort of thing for a while, presumably with the same sentiment as you: why bother installing another instance of Eclipse when I'm already sitting in one all day? However, between Designer's age (it's roughly equivalent to, I think, Eclipse 3.4), oddities when it comes to working sets between the "Applications" and "Project Explorer" views, and, in my case, my desire to use a Mac app, I ended up switching.
There are two major starting points: the XSP Starter Kit (http://www.openntf.org/internal/home.nsf/project.xsp?name=XSP%20Starter%20Kit) and Niklas Heidloff's video on setting up Eclipse for XPages development (http://www.openntf.org/main.nsf/blog.xsp?permaLink=NHEF-8RVB5H). The latter mentions the XPages SDK (http://www.openntf.org/internal/home.nsf/project.xsp?name=XPages%20SDK%20for%20Eclipse%20RCP), which is also useful. In my setup, I found the video largely useful, but some aspects either difficult to find (IBM's downloads are shifting sands) or optional (debugging, which will depend on whether or not you're using Eclipse on Windows).
Those resources should generally get you set up. The main thing to worry about when setting up your Eclipse environment will be making sure your Plug-In Execution Environment is properly done. If you're following the SDK setup instructions, that SHOULD get you where you need to be.
The next thing to know about is the way plugins are structured. Each plugin you want to install in Designer or Domino will also be paired with a feature project (a feature can house several plugins), and potentially an update site - the last one is optional if you just want to import the features into an Update Site NSF. That's how I often do my normal plugin development: export the paired feature to a directory and then import the feature into the server's Update Site NSF and then install in Designer from there using Application -> Install. You can also set things up so that you deploy into the server's plugin/feature directories instead of taking the step of installing into an update site if you'd prefer. GitHub doesn't really come into play for this aspect - it's more about sharing/collaborating with your code and also having a remote storage location for your git repositories (which I highly advise).
And as for the "lost in the woods" feeling: yep, you'll have that for a good while. There are lots of moving parts and esoteric concepts to get a hold of all at once. If you mostly follow the above links and then start with some basics from the XSP Starter Kit (which is itself a plugin project that you can pair with a feature) - say, printing text in the Activator class and making an implicit global variable just to make sure it works - that should help get your feet wet.
It's best done in Eclipse. You can debug your code running on the server from there, as well as run it directly from there. The editors are also more up-to-date. You want:
Eclipse for RCP and RAP developers
XPages SDK for Eclipse RCP (from OpenNTF)
XPages Debug Plugin (from OpenNTF - basically allows you to load the plugins to the Domino server dynamically, rather than exporting to an Update Site all the time)
XSP Starter Kit on OpenNTF is a good starting point for a plugin. There are various references to the library id, which has to be unique for your plugin. Basically, references to org.openntf.xsp.starter need changing to whatever you want to call your plugin. You're also best advised to remove what you don't need. I tend to work in a copy of the Starter, remove stuff, build and if there are errors with required classes (Activator.java obviously will be required and some others), then paste them back in from the Starter.
XPages OpenLog Logger is a good cross-reference, that was built from XPages Starter Kit. It's pretty much stripped down and you'll be able to see what had to be changed. A lot of the elements of the XSP Starter Kit correspond to Java classes you'll probably be familiar with from your XPages Java development.
GitHub etc tend to be used as source control, which is useful for working out what's changed from time to time.
I am having a hard time trying to build my javafx app into .app (for mac).
I found a legit way to do that, here is resource for that:
http://docs.oracle.com/javafx/2/deployment/deploy_quick_start.htm
However, it is far from what I'm looking for. By following that tutorial, I managed to build an app from my javafx project, however the size of file was just ridiculous and it is because the whole JRE is being bundled inside. I am now looking for a way to deploy .app file with dependencies (it's important) ONLY and without JRE. (JRE should be pre-installed by user). Is there a way to do that? I really tried to find one, but faild. Hope you, guys, help me.
Instructions for packaging a JavaFX application as a native installable app without including a JRE:
JavaFX packaging tools update - Self-Contained Applications: Create Package without Java Runtime.
The tools used are the same as from the deployment quick start you mention in your question. You just set the fx:platform basedir="".
I'll just quote the article here:
This may sound a bit puzzling at first glance. Package without embedded Java Runtime is not really self-contained and obviously will not help with:
Deployment on fresh systems. JRE need to be installed separately (and this step will require admin permissions).
Possible compatibility issues due to updates of system runtime.
However, these packages are much much smaller in size. If download size matters and you are confident that user have recommended system JRE installed then this may be good option to consider if you want to improve user experience for install and launch.
Technically, this is implemented as an extension of previous feature. Pass empty string as value for 'basedir' attribute and this will be treated as request to not bundle Java runtime, e.g.
<fx:platform basedir=""/>
my current work tasking requires creating a firefox plugin. I've done this relatively easily on Linux but porting to windows has exposed a peculiar problem. To do the port, I refactored the basic windows example given in the mozilla source tree. I did this operation slowly and methodically, testing as I went. Aside from the occasional OS dependent glitch everything seemed to be going fine until I finally changed the output name of the plugin dll. So, instead of creating a dll called npbasic.dll, the filename was fubar.dll. This immediately caused the plugin to stop working: it did not get picked up in Firefox about:plugins. Changing the filename back to npbasic.dll allowed the firefox plugin tab to "see" the plugin again.
Is anyone aware of an aspect of dll linking/functionality which could be causing this observed dependency?, any help or pointers would be greatly appreciated.
Well, I've done some more research and it's clear that my approach of painstakingly refactoring the example plugin was flawed, the best strategy is to use something like firebreath, as described here : How to write a C++ FireFox 3 plugin (not extension) on Windows?
Today I had a problem with my old Eclipse 3.4 installation and I had to re-download the entire package. However, I don't think that I got the exact package as before, and I'm having some problems.
The problem can be summarized as follows: when developing a plug-in, I cannot resolve dependencies towards 'org.eclipse.jdt.ui'. When trying to add the missing plugin, in the dialog the closest match is 'org.eclipse.jdt.ui**.source**'. A similar thing happens with other core plugins.
In order to test, I created a new plug-in using the wizard and I obtained a non-compiling plugin: one of the classes uses the class org.eclipse.jdt.ui.JavaUI and it cannot be resolved. Similarly, the MANIFEST.MF includes a dependency towards 'org.eclipse.jdt.ui', but the 'Bundle 'org.eclipse.jdt.ui' cannot be resolved'.
Now a summary of my platform:
I'm running Mac OS X 10.4 Tiger and Java 1.5.0_19-138
I'm running Eclipse Version: 3.4.1 Build id: M20080911-1700
I downloaded the modeling package, which comes in a file called 'eclipse-modeling-ganymede-SR1-incubation-macosx-carbon.tar.gz'
I've performed a fresh installation, in a new folder and using a new workspace.
If I look at the Plug-in Registry view, I can find the 'org.eclipse.jdt.ui' plugin in there, and it appears to be running. By the way, if it is disabled, then the workbench breaks and stops working.
I cannot understand what is happening. Is my installation broken? I wonder if the Eclipse package that I downloaded has an error and they included the sources instead of the compiled files. But in that case, the plug-in shouldn't be working in the workbench, isn't it?
In any case, why I cannot find the plug-in when I'm adding the dependencies, even if I see it in the Plug-in Registry?
Thanks for your help!
Problem solved: just restart the computer.
I don't restart my computer very frequently, so it took me a lot of time to find out that this was the solution. After I restarted it, everything started to work perfectly again. It seems that either Eclipse leaves something in the memory after running, or that some of my initial failures had left something nasty behind. In any case, I had checked and there were no Eclipse related processes running .... weird, but at least now it's fixed!