Flash for eComStation
Adobe® Flash® Player is a cross-platform browser-based application runtime that delivers uncompromised viewing of expressive applications, content, and videos across screens and browsers. Flash Player 10.1 and better is optimized for high performance on mobile screens and designed to take advantage of native device capabilities, enabling richer and more immersive user experiences.
For more information about Flash, see:
Mensys BV is allowed to distribute Flash only for eComStation. This is part of the license agreement with Adobe.
We are in GA stage.
The latest version is 0.4.2 released on 24.02.2014.
Changes for 0.4.2:
- Bump wrapper version to 0.4.2 GA.
- Fix crashes after destroying plugin instances. This improves stability on many web-sites.
- Fix crash when using plugin on an unregistered version of eCS.
- Show a proper error dialog when NPSWF32.DLL is not found.
Changes for 0.4.1:
- Bump wrapper version to 0.4.1
- Fix crashing when clearing up the browser history (due to lacking wrappers for ClearSiteData? and GetSitesWithData? callbacks).
- Fix crashes on some sites with specific Flash content (the FPU control word was not set correctly when passing control to the plugin).
- Some Flash Plugin Wrapper specific fixes are present in Odin 0.8.8, please see the changelog file of Odin.
Changes for 0.4.0:
- Bump reported Flash version to 11.5 r502
- Bump wrapper version to 0.4.0
- Some Flash Plugin Wrapper specific fixes are present in Odin 0.8.7, please see the changelog file of Odin.
|GCC 4 Core Libraries||WPI||GCC 4 runtime libraries needed for all ODIN installations.|
|yum install libodin||Installs the basic Odin runtime needed for Odin-based and Odin-ized applications|
|0.4.2||no direct download, see below||Flash Plugin Wrapper for eComStation|
|0.4.1||no direct download, see below||Flash Plugin Wrapper for eComStation|
This product is available for download to all registered users of Software Subscription Services for eComStation. For more information, please visit: http://www.ecomstation.com/subscription/
Reporting bugs and requesting new features is done through the ticket system. You can view existing tickets, add comments to them and create new tickets using the corresponding buttons at the top of every page. If you want to submit a new bug or request a feature, please use the Search function first to make sure there is no ticket for this task already created.
We review the tickets regulary and leave comments if we need more info. So please revisit the Feedback analysis as often as possible. If we leave comment and don't get feedback from the ticket creator, we will close the ticket after some weeks.
Anonymous access to the ticket system has been restricted due to multiple attacks of stupid spammers we've been suffering from lately. In order to create a new ticket or comment the existing one, you need to login with your Netlabs login id. If you do not have a login id, you can request one at http://www.netlabs.org/en/site/member/member.xml. We are sorry for inconvenience, but at the present time this is the only way to avoid extremely annoying spam.
Coding guidelines (for developers only)
To allow proper coding and usage of Trac&Subversion features, it is suggested to follow some guidelines.
First, all commits must belong to a ticket; tickets can be created by project manager or by developers for defect fixing, code enhancements or other tasks.
Tickets will be used to tell other people about problems, and allow discussion of patches or new code added. Subversion commits needs to link their ticket in commit message. This can be done using the following syntax:
svn commit -m "Here are my changes. ticket:1." *.*
Trac timeline will automagically convert 'ticket:1' into the URL of the ticket.
At the same time, the changeset number should be added to the ticket using the following syntax:
(changeset:145) Here are my changes.
This allows following ticket life without looking at timeline changes every time. While the commit message is usually short, developers can add more detailed informations in ticket record. Remember, other developers could not know what you are doing, or understand what has been changed simply looking at code.
Also we need to track changes to avoid regressions as much as possible: exhaustive descriptions makes life much easier when regressions or typos must be fixed.