I have Raize 3.0 installed in D2007. For whatever reason, I can't seem to get the Ctr-click to work for loading up it's units, even though that feature works fine on all my other Delphi and Third-Party components.
Here's what I have for Raize on the Library Path:
$(ProgramFiles)\Raize\RC3\Lib6
$(ProgramFiles)\Raize\RC3\Source
...and the Browsing Path:
$(ProgramFiles)\Raize\RC3\Source
Lib6 contains *.dcu and *.dfm files, and Source contains, obviously, the source code. Adding Lib6 to the Browsing path doesn't seem to affect things one way or the other.
I don't get why this Ctrl-click unit-loading feature isn't working, just for this one component. Any ideas what I may be missing?
You shouldn't need Source path in your Library path. Lib6 should be added to Library Path, and Source to Browsing Path.
If you do so, and it still doesn't work, then you have a similar problem with me:
Problem with setting Browsing Path in Delphi option page
For lib path you generally don't need source files. I use:
C:\Program Files\Raize\RC4\Lib\BDS2007
For browsing path you need to specify the language directory, e.g.:
C:\Program Files\Raize\RC4\Source\Lang\English
If this doesn't fix it, does your unit compile without errors?
Related
I am installing a package manually on my own system because I need to make some changes to it that aren't available in the basic version in my package manager. I also am trying to keep packages installed locally if possible, so I'm installing it with prefix=$HOME/.local instead of the more common prefix=/usr/local.
When I do this, I have no problem executing the program from my terminal, because I added ~/.local/bin to my PATH and the package was installed with relative paths to its shared libraries (i.e. ~/.local/lib/<package>). Executing from the command line is no problem, but I want to be able to access it from the favorites menu in gnome, and for that I need to make use of the <package>.desktop file.
I could hard-code the path to the executable in the .desktop file itself, but when I pull a later version down and re-install it, I'll have to redo those steps. I was wondering if there's a way to avoid that.
I've tried symlinking the executable to a directory where .desktop files do have included in their path, and the application is correctly treated as a GUI option, but launching the executable results in an error trying to find a shared library. I think this has to do with how cmake handles rpaths, which to my understanding is a way of relatively linking executables with their required libraries.
I think what I want to do is have PATH inside a .desktop file include ~/.local/bin, without changing the .desktop file itself. Can I alter the 'default' path used in accessing a .desktop file?
The answer to my question was found in the Archwiki:
Specifically, I needed to add ~/.local/bin to my path in ~/.xinitrc. Now my graphical programs work as expected.
I'm trying to work out how to use DOH to test Dojo modules if I don't install Dojo locally to my project. I'm working in Eclipse and ideally, I'd like something that I can run as part of a Maven build eventually. The Dojo package is 5-20Mb and I don't want to have it stashed in my source control system with each project if possible.
I've tried a few options with the runner.html test runner, but DOH is going to need to find a Dojo somewhere, and then it seems that modules will be found relative to that installation.
Having Dojo installed on my system but not in the project gives me a problem in trying to find the project relative to the location of the dojo.js file. The cross-domain protection prevents me serving up any kind of absolute path as it strips : characters. It also stops me using a Dojo installation served up on a different domain over http.
Is it necessary to have Dojo installed somewhere that I can then define a relative path from dojo.js to the roots of my modules? If not, how do I configure to get around it?
I've not tried this completely cross domain, but yes, you can define paths which may be enough to get you going.
We run our tests using a somewhat complicated deployment (to ensure we don't introduce accidental dojo/doh path dependencies), and our URL looks like this:
http://server/XXX/dev/dohpath/util/doh/runner.html?boot=../../../dojo/dojo.js&dojoUrl=../../../dojo/dojo.js&paths=doh,../dohpath/util/doh;mymodule,../../mymodule&testModule=full.test.module
That is, you fire up the runner, give it both 'boot' and 'dojoUrl' to tell it where Dojo itself lives, use 'paths' to tell DOH where it lives and how to find your own modules.
blech
Whether those relative paths can be made absolute successfuly, and whether it'll work cross-domain is an entirely different matter, I'm afraid. We'll be hitting that problem ourselves in a couple of months.
I've been able to do this with the runner located at http://archive.dojotoolkit.org/nightly/checkout/util/doh/runner.html and a gist.
The trick seems to be to use a path alias in the URL, and use a network-path reference URL (i.e. omit the URL scheme, URL starts with //).
I found this out while trying to answer this question without a local copy of DOH.
Here it is:
http://archive.dojotoolkit.org/nightly/checkout/util/doh/runner.html?testModule=aa&paths=aa,//gist.github.com/gitgrimbo/5406688/raw/e6bc4469ce72dfd6d50e61e885889cb915a3f66b/gistfile1
I'm having an issue with linked Resources in Flash Builder. I work in a team environment where we use Linked Resources extensively. We just started developing ANEs and noticed that while linkedResources are used in the libraryPathEntry, in the buildTargets like anePathEntry and airCertificatePath, the absolute path is stored. I tried editing the .actionScriptProperties files directly, modifying the buildtarget absolute paths to linked resource equivalents using the libraryPathEntry as a guide but FlashBuilder complained when loading the project.
Is there a way to get the buildTargets to respect linkedResources and not save the absolute path? I'm trying to avoid the draconian way where all developers must have the exact same directory structure.
Thanks!
Randy
My team had this exact problem and all attempts to fix it with relative paths or workspace macros (i.e. ${PROJECT_LOC}) failed. It seems as if the team in charge of Flash Builder neglected to support relative paths in these particular dialogs, despite them being supported elsewhere.
Here is what we have done to fix this problem. I am assuming you are on a Mac/Linux or the like. If not, the concept here can still be applied.
Most of our projects already have a "set up" bash script that contributors run when they get code. Inside of that script, we simply set up a couple of symbolic links from the user specific absolute path, to a new absolute path with a "common" user. The script first creates the directory if it does not exist, and then creates the symlinks.
sudo mkdir -p /Users/common/<project>/
sudo ln -f -h -s ~/path/to/certificate/dir /Users/common/<project>/certificates
Obviously you can use whatever you like and whatever makes sense for the common path.
Now, in your .actionScriptProperties file you can change the location pointed to by the provisingFile and airCertificatePath to this new common absolute path.
<buildTarget ... provisioningFile="/Users/common/<project>/certificates/provisionfile.mobileprovision" ... >
<airSettings airCertificatePath="/Users/common/<project>/certificates/cert.p12" ... >
We actually take this a step further (and I suspect you will need to also) and create common symlink paths for the ANE files themselves. This ends up changing the anePathEntry to the common path as well.
<anePathEntry path="/Users/common/<project>/anes/some.ane"/>
You will need to make sure that you either hand edit the .actionScriptProperties file directly, or type in the fully qualified symlink path into the dialogs directly. Any attempt at using the Finder dialog launched by Flash Builder to navigate to the files in the common location resulted in the symlinks being auto-resolved to their actual locations.
The script requires sudo, which as I'm sure you know, will require that the users of it know their root password. Maybe some more bash savvy folks can suggest a way around sudo if this is not an option for you.
This will work for android stuff as well I believe. I don't know if that matters to you or not.
Hope this helps!
It looks like this issue was called out in the Flash Builder 4.6 known issues:
http://helpx.adobe.com/flash-builder/kb/flash-builder-4-6-known.html
https://bugs.adobe.com/jira/browse/FB-32955
The bug is apparently fixed but I haven't been able to check the new Flash Builder 4.7 beta yet:
http://blogs.adobe.com/flex/2012/08/flash-builder-4-7-beta-is-here.html
I have a problem using Intellij Idea.
I am absolutely unable to load text file as InputStream - it doesnt matter where do I put the file (main/java, main/resources...) it just can't find the file - in Eclipse everything works just fine.
I tried setings->compiler->resource patterns and added ?*.txt but that doesn't seem to work either.
Any help is appreciated.
If you load it as a File, make sure that Working Directory is properly set in IDEA Run/Debug Configuration, since it's the default directory where Java will look for a file when you try to access it like new File("file.txt"). Working directory should be set to the directory of your project containing .txt files.
If you load files as a classpath resource, then they should reside somewhere under Source root and will be copied to the classpath according to Settings | Compiler | Resource Patterns.
If you can't get it working, upload your project somewhere including IDEA project files so that we can point to your mistake.
Look at the image, notice that the txt files are in the project root, and not the source folders (in blue).
If you open the Project Structure dialog, and click on Modules and select your module - are the correct folders marked as Source Folders on the sources tab?
Link for how to get to Project Structure dialog
Also, if you print out the absolute path of that file you are trying to read, is that anywhere near where you expect it to be?
An easy way to figure out the same would be to try creating a file in the same fashion and see where it gets created in your project. You can put your input file at the same location and it should work just fine (if it doesn't, you should check your resource pattern which might be causing the file to be not copied over in the build output).
This method actually gives you the working directory of your intellij settings which is pointed out in the accepted answer. Just sharing as I had similar trouble and I figured out this way. :)
If I try to build an application with the application class outside the default package, so the application file path is /app/AppClass.mxml instead of /AppClass.mxml (as would normally be the case), Flash builder cannot launch the application for debugging because it is looking for the SWF in debug/app/AppClass.swf and the SWF is being output to debug/AppClass.swf instead. Changing the output folder to debug/app makes it put the swf in debug/app, but then it puts the application configuration file "AppClass-app.xml" in /debug/app/app and then that can't be found.
Is there a way to change only the SWF output folder, or the location of the xml configuration file in the run-configuration?
You may use symbolic link to created swf file - http://en.wikipedia.org/wiki/Symbolic_link
for example for Windows :
cd project/path/bin-debug/package/path/
MKLINK ClassName.swf project/path/bin-debug/ClassName.swf
and it's work
or you can use symbolic link for folder:
cd project/path/bin-debug/package/
MKLINK path project/path/bin-debug/ /D
I think I remember this worked for me. But it was long time ago. And, yes, it is a known problem, I also recall Adobe people mentioning it as a limitation of FB.
In my Ant script, you'll need to do the adjustments to reflect your actual file names and directory structure. Also note that it will make it more cumbersome to debug it from FB. You'll need to use the debugging target in Ant, and then connect the debugger to the running application (so that some info, especially on the startup) will be lost. The only way you would be able to debug it, though I've never tried it, is with the commandline tools (I'm not sure of adl syntax for breakpoints / printing / stack frames, so idk how to do it.
Also, for the released application you will probably want to change the signing mechanism.