Hi All,
I'd like to know if its possible to maintain destination filename to be similar with the original. This is important as different types of files with different extensions will be sent through EDI and this confuses the import application
You are here
destination filename preservation
Fri, 2006-09-15 13:49
#1
benjie.daud
destination filename preservation
benjie,
this is not possible so far. But anyway this is a good point. I will add it to our tracker.
Best regards
Heller
Hi,
I have implemented it.
Files: http://pronet.lublin.pl/~olejnik/mecas2/b10/
Is there any other way to put you patches?
How does it work? Watch: help-movie-1.html
Film is out of date. Now we can use pattern vs any sender, so patterns contain sender name which help us to divide sender files into inbox subdirectories. I have removed 'only one local station' limit, I have tested it and it seems to be worked ok.
Just download and replace mec_as2.jar.
My changes:
- full-src-b10.zip - full source
- patch-b9-b10.patch - only changes (you can apply this patch using eg. TortoiseCVS)
Heller, whether you can check my changes and apply them in order to create official build 10? Fell free to modify my code.
There are more features which I want to implement:
1. Minimize to try
2. Run as a windows service
3. Log errors via email
4. GUID as a message-id
5. Localization using standard ResourceBoundle (.properties files - see eg. JPanelPartner - JPanelReceive). Support for utf-8. Why did you implement it in the other way?
How about it?
Best regards,
Mariusz
PS. My thanks for your great work!
Mariusz,
thanks a lot for this great piece of work.
We will review your changes and put them to a build 10.
But first I want to answer to your questions..and I have some myself, too :)
Hi,
I have removed 'only one local station' limit, I have tested it and it seems to be worked ok.
What is the idea to remove this limit?
5. Localization using standard ResourceBoundle (.properties files - see eg. JPanelPartner - JPanelReceive). Support for utf-8. Why did you implement it in the other way?
Our ResourceBundles are inherited from ListResourceBundle and should support all that "normal" ResourceBundles support, too. This code is in our products for a long time now and we have choosen to use these classes because it's possible to create Applets fairly fast without code changes.
For your upcoming plans on service wrappers etc we will create a new subforum called addons or something like that where you can feel free to post links to addons/plugins :)
Best regards
Heller
Thanks Mariusz for the solution.
Heller,
Please be patient, my new version will be available very soon: many local stations and many remote partners...
There is no time to lose ;-), I really need this feature.
I will post more info later.
Best regards,
Mariusz
EOT. -> http://www.mec-community.com/node/52