: WARNING - support of the decompiler is now VERY LIMITED. There are no active developers. This means waiting times in the issue tracker are very long and mostly depend on community. Sorry for the inconvenience.

List of issuesList of issues

#1013 Fail to save any SWF that was modified.
Author: user Djamana
Date created:
Type: bug
Visibility: Everybody
Assigned to:
State: new Help

> What steps will reproduce the problem? 1. Open some swf (Debug/Open test SWF as3.swf) 2. Edit a script (scripts/...TestMovie) [Edit] insert some <space> [save] -> I'll marked Bold to show that it has changed 3. File/Save As Test.swf > What is the expected output? What do you see instead? -> there'll be just a Test.swf.tmp with 0 Bytes remark: A quicker way to check instead of save as is 'others/DoABC2()' -> it should marked bold when I click it the screen on the right is NOT updated => if that happens save will definitively fail. > What version of the product are you using? Is it "nightly build"? Which operating system do you have? Version: 6.0.1 Release date: 07/06/2015, 9:19 pm on Win7 64 bit (with Java 8 32-bit) > Please provide any additional information below. If the problem is related to a SWF file, attach it here, otherwise we can't help you. I got Netbeans + src and already located the buggy code: it's here jpexs-decompiler\libsrc\ffdec_lib\src\com\jpexs\decompiler\flash\SWFOutputStream.java @Override public void write(int b) throws IOException { temp[tempPos] = b; // cycle tempPos from 0 to 4 tempPos = ++tempPos % TEMPSIZE; pos++; // Compare b with the data from inputstream int r = is.read(); if ((b & 0xff) != r) { if (ignoreFirst <= 0) { os.flush(); /* boolean output = true; if (output) { System.out.println("Position: " + pos); System.out.print("Last written:");...toHexString(temp[...]).. System.out.println("More expected:");....toHexString(is.read().. System.out.println(Integer.toHexString(r) + " expected but " + Integer.toHexString(b) + " found"); } throw new NotSameException(pos); */ } else { ignoreFirst--; } } os.write(b); } } The NotSameException will smash any upper save Tag/SWF or dumping function. Why is there? If there is made any change more than one byte 'NotSameException' will be raise Seem to be some old debugging code. OffTopic: Made also some changes how to submit them for review? It's my first time using Netbeans + Git. Beside that I may also improve the german translation.
developer
Yes, this is a debug/testing code, when you disable debugCopy you should not see this problem. NotSameException is throwed by CopyOutputStream, and it is used only when debugCopy is enabled. CopyOutputStream is for testing the swf parser and composer. Normally it should not throw this exception, but in some cases the composed data can be compatible but different from the original. So this is not a bug, the users should not use debugCopy (also should not use debug mode), it is for the unit tests (not even for developers)... However it is very interesting, that is fails with the test swfs (as2, as3.swf), because unit test is checking them. I'll investigate it. So please turn off debugCopy and debug mode... you can keep "show debug menu", then let me know when you can reproduce this problem. JPEXS: German translation: There is no update from krock sine 2013 sept, So I think it would be great if Djamana improve it.
developer
debugCopy is called "Debug recompile" in advanced settings.
user
Okay I reset the settings as well as "Debug recompile"- however ohoh an other bug's approaching private byte[] saveToByteArray() throws IOException { ... sos.writeUI8(version); sos.writeUI32(0); // placeholder for file length sos.writeRECT(displayRect); BUGGY >> sos.writeUI8(0); BUGGY >> sos.writeUI8(frameRate); SHOULD BE sos.writeUI16(frameRate); Else writeUI16 cries out "Value is too large for UI8: 6144" but this Exception never makes its way to be shown ...and again save will fail. Okay but finally after fixing that glitch it Saving works again!
developer
Are you sure that it is ok? For example if the framerate is 24, then it should be 00 18 in the file... if you write it as UI16, it will write 18 00 Could you pleaes attach your file?
developer
I think you fix is wrong, so please be careful.. if you save the file with your modified version of FFDec, the result can be corrupt. See the swf documentation: http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/swf/pdf/swf-file-form at-spec.pdf FrameRate UI16 Frame delay in 8.8 fixed number of frames per second SWF 8 and later supports 16 bit 8.8 signed, fixed point numbers. The high 8 bits represent the number before the decimal point, and the low 8 bits represent the number after the decimal point. FIXED8 values are stored like 16 bit integers in the SWF file (using little endian byte order) and must be byte aligned.
user
Oops sorry over read this FIXED 8.8 value thing. And yesterday I was a little to enthusiastic when correcting that tippo tmpFirstByetOfFrameRate to tmpFirstByteOfFrameRate and 'optimizing' so I end up with: frameCount = sis.readUI16("frameCount"); Okay I learned and undo that.
user
Finally I found this solution: frameRate = (int) sis.readFIXED8("FrameRate"); ... sos.writeFIXED8(frameRate ); and discovered some minor bug in writeFIXED8 so 7.5 will get 0x0007 0080 instead of 0x0007 8000 I changed it like this: /** * Writes FIXED8 (Fixed point 8.8) value to the stream * * @param value FIXED8 value * @throws IOException */ public void writeFIXED8(float value) throws IOException { final int FIXED_POINT = 8; final int ONE = 1 << FIXED_POINT; int integerValue = 0xFFFF & (int) (value * ONE); int beforePoint = integerValue >> FIXED_POINT; int afterPoint = integerValue % ONE; writeUI8( afterPoint ); writeUI8( beforePoint ); } to make it correct and nice looking just like: public void writeFIXED(double value) throws IOException { final int FIXED_POINT = 16; final int ONE = 1 << FIXED_POINT; long integerValue = 0xFFFFFFFF & (long) (value * ONE); int beforePoint = (int) integerValue >> FIXED_POINT; int afterPoint = (int) integerValue % ONE; writeUI16( afterPoint ); writeUI16( beforePoint ); }
developer
"and discovered some minor bug in writeFIXED8 so 7.5 will get 0x0007 0080 instead of 0x0007 8000" FIXED8 is 2 bytes... how is it possible that it writes 0x0007 0080? For me it seems to be ok. Please also check the testFIXEDandFIXED8 in SWFStreamTest.java
developer
I changed the framerate to float number. Please check my commit: https://github.com/jindrapetrik/jpexs-decompiler/commit/809091ea42cbbb8870359ab12ee98db337 ee876d
user
Wow nice I see you did it. Also tried this but then decided to keep it at int since that ended up in kind of smaller a'undertake'. I would love to discuss somewhat more about 'sos.writeFIXED8' via github - instead of posting code in here. However before it's good to learn more about how to work with github... Well yesterday I roughly finish the german translation for MainFrame_de.properties and today I managed to upload them to git: https://github.com/Djamana/jpexs-decompiler/commit/e117ba528f6d7b67b88876d11782f44e344f005 b But yes some questions came up #1 Wanna find out how to update/merge your last commit into the fork I created yesterday. (instead of delete and reforking it) ...and #2 how to make and addition to a commit / joining two commits. Hmm read somewhat about rebase / squish... If ya like/have time we may also voice chat via Skype or better via Teamviewer <-so you see what I see on the screen/ move the mouse / operate the keyboard via remote
admin
Visibility: Everybody→Everybody
admin
Is this issue solved? Can it be closed?
 
Google Translate: Translate to Czech Translate to Slovak Translate to Russian Translate to Hungarian Translate to Swedish Translate to French Translate to German Translate to Spanish Translate to Italian
Change style: oceanic classic