I'm using Record editor to generate my classes, but I have two imports that doesn't work
import net.sf.JRecord.def.IO.builders.ICobolIOBuilder;
and
JRecordInterface1.COBOL
I'm using JRecord 0.80 and I can't upgrade to 0.90, is there any way to generate the code from Record Editor to JRecord 0.80? I think this may be the problem
You are likely correct, JRecordInterface1.COBOL was introduced in version 0.8?.?, so is not available in earlier versions of JRecord. It would be useful to know the actual version of JRecord being used.
You might be able to replace JRecordInterface1.COBOL with CobolIoProvider.getInstance() in the generated code. Again CobolIoProvider.getInstance() might not be available depending on there version version of JRecord being used.
External Templates
You can use an external templates in the RecordEditor instead of the supplied templates.
JRecord 0.80 Template
There is a JRecord 0.80 Template StandardTemplate_For_jrecord_0.80_V01.00.zip
at JRecord Templates
Using JRecord 0.80 Template
In the RecordEditor
Select Generate >>> Java JRecord Code for Cobol
Enter the Cobol Copybook and optionally the Cobol Data file. Also Select
the Drop copybook names from field names option.
Enter the StandardTemplate_JRecord_080 directory in the template directory field.
Hit the next button to generate the template.
Setting the JRecord Version
There is an option on the Generate screen to set the JRecord version, the earliest version supported is 81.5. Not much use to you but may be useful for others.
Related
After upgrading Devexpress VCL from 18.2.5 to 19.1.2, in order to use the latest functions and especially the new grid Excel filtering mode,
but unfortunately, the compiler didn't recognize some constants and properties, like the dxDefaultFilterPopupWindowMode constant and
.Filtering.ColumnPopupMode property of DBGridViews.
In spite of putting dxFilterPopupWindow in the uses clause.
Any help ?
Today I upgraded from version 18.1.2 to the most recent version of the DevExpress VCL library,
which is version 19.2.4 dated 22 January 2020 and adapted an existing minimal cxGrid
project to use the new Excel-style filtering. It compiled and executed without any error.
Here's what I did:
1 My existing Devex install folder (the one you tell the installer to use) is D:\DevExpress VCL
2 I renamed D:\DevExpress VCL to D:\DevExpress VCL Prev
3 I ran the 19.2.4 installer, giving D:\DevExpress VCL as the install folder to use.
You mention the compiler complains about the identifiers dxDefaultFilterPopupWindowMode and
ColumnPopupMode. You say "In spite of putting dxFilterPopupWindow in the uses clause.
dxDefaultFilterPopupWindowMode is declared at line 50 of dxFilterPopUpWindow.Pas
const
dxDefaultFilterPopupWindowMode: TdxFilterPopupWindowMode = fpmClassic;
and ColumnPopupMode is declared at line 3361 of cxGridTableView.Pas:
TcxGridTableFiltering = class(TcxCustomGridTableFiltering)
[...]
published
[...]
property ColumnPopupMode: TdxFilterPopupWindowMode read GetColumnPopupMode write SetColumnPopupMode default fpmDefault;
end;
I strongly suggest that you install version 19.2.4 in the way I've described above, then check that your
project's search path includes the path to the Devex sources. Of course, if you follow the method I've described, the project search path should not need changing, if it compiled previously.
If the compiler still complains about
not being able to find dxDefaultFilterPopupWindowMode and ColumnPopupMode, then assuming you are
not compiling your project to use run-time packages, the only possible cause I can think of
is that the compiler is finding earlier versions of dxFilterPopUpWindow.Dcu and cxGridTableView.Dcu that
somehow have later date stamps than the corresponding .PAS files - in that case I would delete all instances
of the Devex Dcu's from my system and try again. A way to ensure that the compiler is compiling the
version of the Devex source files that you think it is is so edit cxGridTableView.Pas to add a "compiler stopper"
such as an exclamation mark at the very top of the file: If the compiler does not complain about this
when trying to compile your project, you'll know that it's finding and using another version of the
cxGridTableView .Pas file or .Dcu.
Finally,
This error occurred because I left the path of the previous version in the Delphi library path, and it was before the path of the new version.
So, I deleted the 1st one and I kept the new one.
Et voila, all things runs well now :):):)
Currently, when displaying (downloading) my .xpt bipublisher report as a .xlsx, my only sheet's name is Sheet1. I would like to rename it.
I know you can create xls templates directly and simply rename the sheet, but I'd need to recreate the whole report...
For RTF templates, you can specify a spreadsheet-sheet-name command.
This is from the Oracle Fusion Middleware Report Designer's Guide for Oracle Business Intelligence Publisher - 11g Release 1 (11.1.1) regarding RTF templates:
<?spreadsheet-sheet-name: xpath-expression?>
Where xpath-expression is an XPath expression or a string constant.
The example given is:
<?spreadsheet-sheet-name: {concat(.//YEAR, ' ',.//STATE)}?>
(The guide for 12.2.1 has the same; I do know know about anything prior to 11.1.1.)
Using a RTF you can actually created multi-sheet excel file and also you can rename the sheet. In order to create multiple sheet you need the following instruction:
<?split-by-page-break:?>
And before that instruction you need you use this one:
<?spreadsheet-sheet-name: xpath-expression?>
Next some examples:
<?spreadsheet-sheet-name: {concat(.//name, '')}?> --> It concatenates
<?spreadsheet-sheet-name: {.//name}?> --> It only use the XML field
<?spreadsheet-sheet-name: {normalize-space(upper-case(.//name))}?> --> It applied a trim and upper functions
In my case in my XML data file, i have this field called "name" in a third level:
<sales>
<division>
<name>Groceries</name>
<year>2014</year>
<totalsales>3810</totalsales>
<costofsales>2100</costofsales>
</division>
<division>
...
I use java and saxonee-9.5.1.6.jar included build path , when run, getting these errors at different times.
Error at xsl:import-schema on line 6 column 169 of stylesheet.xslt:
XTSE1650: net.sf.saxon.trans.LicenseException: Requested feature (xsl:import-schema)
requires Saxon-EE
Error on line 1 column 1
SXXP0003: Error reported by XML parser: Content is not allowed in prolog.
javax.xml.transform.TransformerConfigurationException: Failed to compile stylesheet. 1 error detected.
I open .xslt file in hex editor and dont see any different character at the beginning AND
I use transformerfactory in a different project but any error I get.
Check what the implementation class of tFactory is. My guess is it is probably net.sf.saxon.TransformerFactoryImpl - which is basically the Saxon-HE version.
When you use JAXP like this, you're very exposed to configuration problems, because it loads whatever it finds sitting around on the classpath, or is affected by system property settings which could be set in parts of the application you know nothing about.
If your application depends on particular features, it's best to load a specific TransformerFactory, e.g. tFactory = new com.saxonica.config.EnterpriseTransformerFactory().
I don't know whether your stylesheet expects the source document to be validated against the schema, but it it does, note that this isn't automatic: you can set properties on the factory to make it happen.
I would recommend using Saxon's s9api interface rather than JAXP for this kind of thing. The JAXP interface was designed for XSLT 1.0, and it's a real stretch to use it for some of the new 2.0 features like schema-awareness: it can be done, but you keep running into limitations.
I am converting DITA to XLIFF. In my technical solution I have to specialize (modify) xliff-core-1.2-strict.xsd to accommodate few DITA attributes. It means some attributes will go along with "g" tag. For Example:
<g id="00001" newAtt="this is new attribute" xid="009"/>
From the translation side I am not sure how it will work, so my questions:
Is it general practice that LSPs will get different flavor of XLIFF XSDs from different companies?
And is it possible for them to use it in their XLIFF editor by updating updated XLIFF XSD? I tried to explore “Transolution” but did not find any place where to place modified XSD.
Please let me know if you have any thought on this.
Thanks.
Here are my answers to your two questions:
I work for an LSP and I've seen all sorts and flavors of Xliff. Most of them try to stick to OASIS 1.2 transitional schema. Some of TMS/CAT producers added their own extensions. These producers normally provide an XSD so you can validate their Xliffs by adding that XSD to OASIS schema; e.g. SDL extensions to 1.2. When I'm customizing Xliff for a client, I normally do namespaces and provide a simple additional XSD; e.g.:
<trans-unit id="0" translate="yes" resname="msg_foo">
<superduper:uri>http://foo.bar/iJKLM9</superduper:uri>
<source>This is supposed to be a <superduper:g id="00001" newAtt="this is new attribute" xid="009"/> example.</source>
<target state="new"></target>
</trans-unit>
Most of the TMS/CAT tools are very basic (and closed) when it comes to their Xliff filters (or any of their filters for that matter) and I'm sorta kinda sure that they ignore your customized XSD.
Transolution is a very nice tool and my favorite Open Source translation tool. Unfortunately it's been long abandoned and has plenty of defects and shortcomings.
Anyway, if you provide a sample file, I can tell you what happens to non-conforming tags when it's imported into one of common, major CAT tools.
One final note; <g> seems to be retired in Xliff 2.0.
Forget about Transolution for one thing. I would try it with Trados, MemoQ or MemSource. Those are some of the big tools used in the translation business.
Personally I never got an XLIFF with a XSD, nor do I think Trados can handle it.
What do you need to change in the XLIFF?
In Delphi there is an option VersionInfo->Language->Locale ID when viewing project properties.
I was wandering how to set such property for a program being compiled under Free Pascal.
Any solution is welcome: command line argument or preprocessor directive such as {$key value}; equivalent to Delphi.
If you can build your projects using *.lpi files then I would try to add the following into your project's Project.lpi file. In the following snippet is shown how to set the project's locale ID (for Windows platform) to 0405 (Czech).
<?xml version="1.0"?>
<CONFIG>
<ProjectOptions>
...
<VersionInfo>
<UseVersionInfo Value="True"/>
<Language Value="0405"/>
<StringTable ProductVersion=""/>
</VersionInfo>
...
</ProjectOptions>
...
</CONFIG>
Or if you are using Lazarus IDE then you might use to Delphi very similar settings tab which you can open from Project / Project Options ... and as in Delphi go to Version Info where is the Language selection combo box available if you include the version info into the project.
Not 100% sure this will work, feel free to vote me down if this doesn't work.
Lazarus will inherit the locale settings it starts with.
You can set the locale info prior to starting Lazarus in Linux/OS X using the command line:
export LC_CTYPE="pt_BR"
export LANG="pt_BR"
export LANGUAGE="pt_BR"
./lazarus
Your compiled application should inherit these settings.
The answer is inspired by this workaround to an error has since been fixed.
I recommend you have a look at the fpc forum as well and ask the question there.
Don't forget it include details like the platform (Linux/Windows/OS X) and the exact version of FPC and Lazarus you are using as well as the actual Locale that you want.
Better answer
From: http://forum.lazarus.freepascal.org/index.php/topic,5924.0.html
Finally, I managed to find a simple and effective way to make my application localizeable. It uses just one unit and no code.
1. Add unit "defaulttranslator" to your uses list.
2. Enable "i18n" in "Project Options" and set "PO output directory" to "locale" or "languages". You can put translation files right into application folder, but that would just make a mess. Don't forget to create an appropriate folder.
3. Add components to the form. If you already have all components on your form, you'll have to move it a little bit, so it's modified.
4. Save your project.
5. Now there should be .po files in your "locale" or "languages" folder. For different languages files should be copied and renamed like so "project1.XX.po", where XX is language code (e.g. "en", "de", etc.).
6. Translate .po files with translation software, and generate .mo files. I suggest to use POEdit.
7. Run your application, and the translation to be used will be chosen by your regional locale settings. If you need to test other language - just start your application with following command line parameters - "-l XX" or "-lang XX", where XX is a language code.
This method is not very versatile, but it translates resource strings and LCL component properties.