I am struggling with opening a PDF file as a user's documentation in JavaFX program.
Code works fine whenever I open it using IDE. The problem begins when I build my program and try to open it from distributions folder.
For example, this method works, when I am using IDE:
public void helpButtonOnAction(ActionEvent actionEvent) {
File file = new File("src/main/resources/pl/com/buleek/docs.pdf");
hostServices.showDocument(file.getAbsolutePath());
}
But obviously, when I pack my program with gradle build, it is in a directory:
C:\Users\Matthew\Desktop\xxx\ProgramNameFolder\build\distributions\ProgramName\bin
And from now on, it can't see src/main/recources/pl/com/buleek/docs.pdf, because in ProgramNameFolder there are only bin with ProgramName.bat and lib folders.
Is there a way (after building distributions) to paste another folder inside my ProgramName folder, put there my docs.pdf file, and then set code like:
public void helpButtonOnAction(ActionEvent actionEvent) {
File file = new File("ProgramName/docs/docs.pdf");
hostServices.showDocument(file.getAbsolutePath());
}
Or shall I use some command to pack pdf file with my program?
Your build tool will usually place your resources in a jar. As your PDF file is already in your resources folder, it should be packaged into your application jar by default.
You can read resources from your jar file via YourClass.class.getResourceAsStream(), then write the stream to a temp file using basic Java I/O APIs, specifically the version of Files.copy(...) which takes an input stream as a parameter.
The intermediate step of extracting the PDF file from your jar and writing to a temp file in the file system is necessary because you are using host services to launch an external browser and, unlike java, the external browser will be unable to directly read resources from a jar file.
You can convert the file name of the temporary file to a URL string and show it via HostServices.showDocument(uri) as you are currently doing.
If the browser is capable of displaying PDFs (most are) then the PDF will be displayed in the browser, otherwise, the browser will usually allow the user to download the PDF to a file location of their choice on their machine and open the PDF via an external application.
Related
I have a foo.txt file in my /war folder. I'm trying to open it using the File class, but get an exception:
java.security.AccessControlException: access denied (java.io.FilePermission
/foo.txt read)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:374)
at java.security.AccessController.checkPermission(AccessController.java:549)
...
From reading the docs on static/resource files, it seems like the text file should already be available. Does it need some extra setting to allow reading?:
https://developers.google.com/appengine/docs/java/config/appconfig?hl=en#Static_Files_and_Resource_Files
I'm using the local dev server on a mac.
Thanks
I suggest that if you are going to read data files in your Java code and need a place to put your data files (.txt or .csv), etc -- then do the following:
Go to WEB-INF folder
Create some folder inside of the WEB-INF folder. e.g. WEB-INF\data
Place your files in the above folder. E.g. sample.txt
In your Java IO code, you can then refer to the file via WEB-INF\data\sample.txt
I created a WPF test project, single Window with a single button in it. I then unloaded the project and modified the csproj to contain the following <UICulture>en-US</UICulture>. After rebuilding the build folder now contains a subfolder named en-US and it contains a file called WpfLocalizationTest.resources.dll. All clear so far.
Then I downloaded the source code for Locbaml and built it. (Couldn't find a binary download anywhere, go figure.)
Then I copied the Locbaml.exe to the en-US folder and tried the following.
locbaml /parse WpfLocalizationTest.resources.dll /out:test.csv
This results in an error 'Could not load file or assembly WpfLocalizationTest.resources.dll or one of its dependencies. An attempt was made to load a program with an incorrect format.'
In the obj\x86\Debug folder there's a file called WpfLocalizationTest.g.en-US.resources. I tried running locbaml on that, but the result was the same.
How is locbaml supposed to be used? MSDN is full of cockamamie samples, none of which work. Is locbaml really how Microsoft intends WPF apps to be localized? Or have they come up with proper tools for the job?
As I continue to search I found another link here on Stackoverflow. The compile errors we were originally receiving were related to an outdated LocBaml project not being set for .Net4.0. This is why I was unable to generate teh CSV from the DLL and had to go straight at the resource file. Follow this link for more details. Locbaml localization of .net wpf4 application
This link provides a link to .net 4 binaries which once compilied allow you to go straight at the dll to generate the CSV using LocBaml.
Just an update I pulled my notes this morning. Hopefully this will help get you a bit further along.
Once the project has been compiled copy the LocBaml.exe to the project directory where the build has been generated : In my instance I copied the file to E:\localiztion_sample\localiztion_sample\obj\x86\Release
This is the tricky part in that the build did not contain all the DLL files from the bin directory (telerik controls and other assemblies). As a result I went to bin\release\ and copied all the DLL and resource files from there into the obj\x86\Release directory. For files where I was prompted to overwrite I looked to see if there was a difference in filesize or date created and if not I skipped the copy for these objects.
NOTE: In order for me to generate the CSV I had to copy dll and resource files from the bin directory and place them in the obj directory. Omitting this step will result in the CSV file being created but not populated with data.
Once you have copied the necessary files to the directory you will then parse the .resource file located within the Release directory.
In my project the resource file was located at:
E:\localiztion_sample\localiztion_sample\obj\x86\Release
And the file name was titled: localiztion_sample.g.en-US.resources
Note: this is different from the instruction on the Microsoft website. Microsoft states that you should run the LocBaml tool on the dll file located within the en-US directory. However after multiple attempts and research I found that this in fact caused a number of problems with compatibility between 32 and 64-bit builds as well as it just flat out not working.
In reading through wpf4 unleashed as well as online forums it is suggested to instead point to the *.gen.en-Us.resources file. * = the project name and gen.en-Us reflects the development language chosen
Within the VS command untility you will then need to enter the following
LocBaml /parse filename.resources /out: sample-en.csv
Notes: It is assumed that you have copied the LocBaml file to the root directory where this file exists and that you are running the command prompt as system administrator. For ease of use I changed the working directory within the command prompt to the VS project directory
For my sample project the command looked as:
*LocBaml /parse localization_sample.g.en-US.resources /out: sample-en.csv*
This command then generates the CSV file which acts as a definition of the current project
This was as far as I got I was able to modify teh file and regenerate the dll but I was not able to get the culture to change within the application so I am still working on this piece. I'll reposte once I get it working.
1) Unload project you want to localise
2) Edit Project .cproj file
3) Add property group at the end of the last property group
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == Release|AnyCPU' ">
<DebugType>pdbonly</DebugType>
<Optimize>true</Optimize>
<OutputPath>bin\Release\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
<PlatformTarget>x86</PlatformTarget>
</PropertyGroup>
en-GB
4) Reload project and compile this would create a satellite assembly "yourlibrary.resources.dll" inside en-GB folder at bin\debug location, this assembly would be the default assembly.
5) Open Properties\AssemblyInfo.cs file and uncomment this line [assembly: NeutralResourcesLanguage("en-GB", UltimateResourceFallbackLocation.Satellite)] this is a fallback satellite assembly. And we need this entry otherwise for wpf application it throws exception around app.xaml.cs couldn't load
6) From command prompt run this command which uses msbuild to generate UID C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild /t:updateuid . \yourlibrary.csproj, open xaml file and check your controls there would be UID on all elements.
7) Download locabaml.exe source code tool from https://github.com/JeremyDurnell/locbaml
8) Copy locabaml.exe file to the \yourprojectname\bin\debug folder
9) we would now create an satellite assembly for french. First we need to parse the default satellite assembly and write out the contents to a csv file as shown here
10:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild /parse C:\yourprojectname\bin\Debug\yourlibrary.resources.dll /out:C:\yourprojectname\bin\Debug\yourlibrary.resources_FR.csv
11) Open yourlibrary.resources_FR.csv make necessary translations
12) Now we need to create a satellite assembly in french using command line
13) C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild /generate C:\yourprojectname\bin\Debug\yourlibrary.Resources.dll /trans: C:\yourprojectname\bin\Debug\yourlibrary.resources_FR.csv /out:C:\yourporjectname\bin\Debug\temp /cul:fr-FR
14) The command above would create a folder fr-FR at \bin\debug location
15) Switch your computer region settings to french(France)
16) In the code set localisation to Thread.CurrentThread.CurrentCulture = CultureInfo.CurrentCulture;
Thread.CurrentThread.CurrentUICulture = CultureInfo.CurrentUICulture;
17) Compile and run application you would see translated text on the controls
I get "Error opening ... file ... (No such file or directory)". However I do not control the file access - a third-party library is trying to open a file in the .war.
It works fine when using an open directory structure on my own computer.
My question is: is normal file access supposed to work within a .war? If not, should I just deploy a directory instead of a .war? Or is there a better way?
Am using glassfish.
.war file should be unpacked by your (application) server, so your third-party lib should operate with files from unpacked .war.
I have a little GWT/AppEngine Project which uses RPC. Basically I need to get some data from a XML file that resides on the server. But when I use the RPC to read the file in my server-package I am getting a AccessControlException (access denied). Any ideas what the problem is?
//JAXB powered XML Parser
public PoiList readXML() {
try {
unmarshaller = jaxbContext.createUnmarshaller();
unmarshaller.setEventHandler(new XMLValidEventHandler());
db = (PoiList) unmarshaller.unmarshal(new File("src/com/sem/server/source.xml"));
} catch (JAXBException e) {
e.printStackTrace();
}
return db;
}
java.security.AccessControlException: access denied (java.io.FilePermission \WEB-INF\classes\com\sem\server read)
cheers hoax
I think the problem is that you're trying to read a file that is not located in your working directory. The guidlines for structuring your code in gwt apps are as follows
Under the main project directory
create the following directories:
src folder - contains production Java source
war folder - your web app; contains static resources as well as compiled output
test folder - (optional) JUnit test code would go here
Try moving the file to the war directory (for example /war/resources/myFile.xml) and then open it by
File myFile = new File(System.getProperty("user.dir") + "/resources/myFile.xml");
Usually, when you load a resource that is located in your classpath, you should't use java.io.File. Why? Because it's very much possible, that there is no real file - the classes are often packaged as a .jar file, or even loaded in a completely different way (very likely in the case of AppEngine, though I don't know the details.)
So, if you want to load it directly from your classpath, you can use:
ClassLoader classLoader =
getClass().getClassLoader(); // Or some other way to
// get the correct ClassLoader
InputStream is = classloader.getResourceAsStream("/com/sem/server/source.xml");
Then you can use the input stream in your unmarshaller.
I use JDIC in my executable Jar file, when it runs, it needs to have IeEmbed.exe and MozEmbed.exe in the same dir as the Jar file, I wonder if there is a way to package all 3 files into a single executable Jar file, so when I distribute the app, there is only one executable Jar file to worry about, besides, there are problems sending and downloading *.exe files, what's the solution ?
For instance, my executable Jar file is called Java_App.jar, how to get <1>IeEmbed.exe <2>MozEmbed.exe and <3>Java_App.jar into a Jar file called : My_App.jar, and when user double clicks on My_App.jar, it will run the Java_App.jar and find the needed IeEmbed.exe and MozEmbed.exe files from inside the My_App.jar package without unpacking and save them into a local dir.
There is no problem packaging them together per se. The jar file is finally a .zip file.
The problem will come when your app try to load it because it won't be able to find the .exe in the system path.
The solution is to make an installable file ( which can be a .zip file ) and expand and copy the .exe file for you for instance in a "bin" directory