I ran through an encrypted SWF yesterday, and I could note a part of actionscript as follows:
if(19228849284 == 192246636643) {
... //other statements continued
}
My question is, how could that code ever get executed?
It looks like the comparison of two timestamps. Perhaps for whatever reason these timestamps are hardcoded in the application and compared at this point. The code obviously won't be executed. Actually, it's strange that the Flash compiler didn't optimize it out.
Related
I'm working with appBuilder and procedure editor in Progress Release 11.6.
As mentioned in some previous questions, regularly I'm having problems with the appBuilder, not wanting to open files, corrupting them (deleting parts of source code), ..., one of the reasons now seems to be the limit that a procedure cannot exceed 32K, comments included.
At first I thought "Are we back in the stone age?", pardon my reaction.
But now I start thinking that we are completely abusing the whole concept, therefore I'd like to show my view on W-, P- and I-files, please confirm (or correct):
W-files are meant only to contain GUI definitions, like a form with some frames, buttons, fill-in fields, ..., any real programming needs to be done in P-files.
P-files contain the real intelligence: there the procedures and functions are elaborated, that can be used by the rest of the P-files, or finally by the W-files.
I-files are just there to include general behaviour.
Let me give you an example:
W-file:
DEFINE VARIABLE combo_information VIEW-AS COMBOBOX /* with some information on the content, if this is static */
...
ON CHOOSE OF combo_information DO:
RUN very_large_procedure.
END.
...
{about.i} /* see here-after */
...
P-file:
PROCEDURE very_large_procedure:
DO /* a lot */
END.
I-file (about.i):
/* Describes the help-about menu item */
While working like this (only putting the GUI-related things in the W-file and let the "real" programming be done in the P-files), the mentioned 32K limit will never be reached. In top of that, adding a procedure can be done easily, the appBuilder will not delete it as the appBuilder won't ever open the P-file.
Is my view correct (and what about the I-files)?
In case yes: one technical question: how can I launch a procedure from a P-file inside a W-file? (Obviously, the mentioned example can't work as in the W-file I did not mention where to look for the very_large_procedure)
The naming is arbitrary and you may occasionally find other extensions being used. Having said that:
"W" is for "window", it is supposed to contain code that is related to making a GUI work. It is very often abused to contain any sort of code. It is usually abused in that way by people who learned to code on the app builder or who have never coded on anything but Windows.
"P" is for "Progress" and retconned to "Procedure". It was the standard back in the old days prior to the appearance of Windows GUI code. Any "headless" code or character mode code would typically go into a dot-p file.
"I" is for "include". This is a very old school way to create reusable code snippets and common "header files". Include files are commonly parameterized. Potentially with either named or positional arguments.
Another major extension is ".cls" files. These are for OO4GL classes (OpenEdge 10 and above).
Launching procedures is acheived by running them:
RUN myproc.p.
or
RUN guiproc.w.
Or, if by "launch", you mean "start a session" then you use the "-p procedureName" startup parameter along with prowin32.exe or prowin.exe for Windows GUI code or _progres.exe for batch or character code.
I am currently working with python and Qt which is kind of new for me coming from the C++ version and I realised that in the oficial documentation it says that an UI file can be loaded both from .ui or creating a python class and transforming the file into .py file.
I get the benefits of using .ui it is dynamically loaded so no need to transform it into python file with every change but what are the benefits of doing that?, Do you get any improvements in run time? Is it something else?
Thanks
Well, this question is dangerously near to the "Opinion-based" flag, but it's also a common one and I believe it deserves at least a partial answer.
Conceptually, both using the pyuic approach and the uic.loadUi() method are the same and behave in very similar ways, but with some slight differencies.
To better explain all this, I'll use the documentation about using Designer as a reference.
pyuic approach, or the "python object" method
This is probably the most popular method, especially amongst beginners. What it does is to create a python object that is used to create the ui and, if used following the "single inheritance" approach, it also behaves as an "interface" to the ui itself, since the ui object its instance creates has all widgets available as its attributes: if you create a push button, it will be available as ui.pushButton, the first label will be ui.label and so on.
In the first example of the documentation linked above, that ui object is stand-alone; that's a very basic example (I believe it was given just to demonstrate its usage, since it wouldn't provide a lot of interaction besides the connections created within Designer) and is not very useful, but it's very similar to the single inheritance method: the button would be self.ui.pushButton, etc.
IF the "multiple inheritance" method is used, the ui object will coincide with the widget subclass. In that case, the button will be self.pushButton, the label self.label, etc.
This is very important from the python point of view, because it means that those attribute names will overwrite any other instance attribute that will use the same name: if you have a function named "saveFile" and you name the button "saveFile", you won't have any [direct] access to that instance method any more as soon as setupUi is returned. In this case, using the single inheritance method might be helpful - but, in reality, you could just be more careful about function and object names.
Finally, if you don't know what the pyuic generated file does and what's it for, you might be inclined to use it to create your program. That is wrong for a lot of reasons, but, most importantly, because you might certainly realize at some point that you have to edit your ui, and merging the new changes with your modified code is clearly a PITA you don't want to face.
I recently answered a related question, trying to explain what happens when setupUi() is called in much more depth.
Using uic.loadUi
I'd say that this is a more "modular" approach, mostly because it's much more direct: as already pointed out in the question, you don't have to constantly regenerate the ui files each time they're modified.
But, there's a catch.
First of all: obviously the loading, parsing and building of an UI from an XML file is not as fast as creating the ui directly from code (which is exactly what the pyuic file does within setupUi()).
Then, there is at least one relatively small bug about layout contents margins: when using loadUi, the default system/form margins might be completely ignored and set to 0 if not explicitly set. There is a workaround about that, explained in Size of verticalLayout is different in Qt Designer and PyQt program (thanks to eyllanesc).
A comparison
pyuic approach
Pros:
it's faster; in a very simple test with a hundred buttons and a tablewidget with more than 1200 items I measured the following bests:
pyuic loading: 33.2ms
loadUi loading: 51.8ms
this ratio is obviously not linear for a multitude of reasons, but you can get the idea
if used with the single inheritance method, it can prevent accidental instance attribute overwritings, and it also means a more "contained" object structure
using python imports ensures a more coherent project structure, especially in the deployment process (having non-python files is a common source of problems)
the contents of those files are actually instructive, especially for beginners
Cons:
you always must remember to regenerate the python files everytime you update an ui; we all know how easy is to forget an apparently meaningless step like this might be, expecially after hours of coding: I've seen plenty of situations for which people was banging heads on desks (hopefully both theirs) for hours because of untraceable issues, before realizing that they just forgot to run pyuic or didn't run it on the right files; my own forehead still hurts ;-)
file tracking: you have to count two files for each ui, and you might forget one of them along the way when migrating/forking/etc, and if you forgot an ui file it possibly means that you have to recreate it completely from scratch
n00b alert: beginners are commonly led to think that the generated python file is the one to be used to create their programs, which is obviously wrong; unfortunately, the # WARNING! message is not clear enough (I've been almost begging the head PyQt developer about this); while this is obviously not an actual problem of this approach, right now it results in being so
some of the contents of a pyuic generated files are usually unnecessary (most importantly, the object name, which is used only for specific cases), and that's pretty obvious, since it's automatically generated ("you might need that, so better safe than sorry"); also, related to the issue above, people might be led to think that everything pyuic creates is actually needed for a GUI, resulting in unnecessary code that decreases its readability
loadUi method
Pros:
it's direct and immediate: you edit your ui on Designer, you save it (or, at least, you remember to do it...), and when you run your code it's already there; no fuss, no muss, and desks/foreheads are safe(r)
file tracking and deployment: it's just one file per ui, you can put all those ui files in a separate folder, you don't have to do anything else and you don't risk to forget something on the way
direct access to widgets (but this can be achieved using the multiple inheritance approach also)
Cons:
the layout issue mentioned above
possible instance attribute overwriting and no "ui" object "containment"
slightly slower loading
path and deployment: loading is done using os relative paths and system separators, so if you put the ui in a directory different from the py file that loads that .ui you'll have to consider that; also, some package managers use to compress everything, resulting in access errors unless paths are correctly managed
In my opinion, all considering, the loadUi method is usually the better choice. It doesn't distract me, it allows better conceptual compartmentation (which is usually good and also follows a pattern similar to MVC much more closely, conceptually speaking) and I strongly believe it as being far less prone to programmer errors, for a multitude of reasons.
But that's clearly a matter of choice.
We should also and always remember that, like every other choice we do, using ui files is an option.
There is people who completely avoids them (as there is people who uses them literally for anything), but, like everything, it all and always depends on the context.
A big benefit of using pyuic is that code autocompletion will work.
This can make programming much easier and faster.
Then there's the fact that everything loads faster.
pyuic6-Tool can be used to automate the call of pyuic6 when the application is run and only convert .ui files when they change.
It's a little bit longer to set up than just using uic.loadUi but the autocompletion is well worth it if you use something like PyCharm.
I have implemented a simple sync routine using the as3commons-async framework (which I thought to be stable as a rock)
I have a CompositeCommand containing a high number of other commands, which can also be composite commands.
Now some strange thing happens:
When executed slowly (over the web) everything works as expected.
Now I leave out the part doing the heavy load causing the commands to run at "machine" speed.
After a couple of dozens, sometimes more than a hundred "progress" events fired, AIR player crashes with this error message:
undefined
at org.as3commons.async.operation.impl::AbstractProgressOperation/dispatchProgressEvent()[C:\projects\as3-commons\as3-commons-async\src\main\actionscript\org\as3commons\async\operation\impl\AbstractProgressOperation.as:135]
at org.as3commons.async.command.impl::CompositeCommand/onCommandResult()[C:\projects\as3-commons\as3-commons-async\src\main\actionscript\org\as3commons\async\command\impl\CompositeCommand.as:287]
at flash.events::EventDispatcher/dispatchEventFunction()
at flash.events::EventDispatcher/dispatchEvent()
at org.as3commons.async.operation.impl::AbstractOperation/dispatchCompleteEvent()[C:\projects\as3-commons\as3-commons-async\src\main\actionscript\org\as3commons\async\operation\impl\AbstractOperation.as:152]
looking at the AbstractProgressOperation code in the async lib at the given line, there's nothing really done there:
/**
* Convenience method for dispatching a <code>OperationEvent.PROGRESS</code> event.
* #return true if the event was dispatched; false if not
*/
protected function dispatchProgressEvent():void {
dispatchEvent(OperationEvent.createProgressEvent(this));
}
I can rule out my code as the culprit as well, as all parts of it are working seperately and are tested in many other aspects. Plus I don't really do anything either right now other than calling execute() on the command and fire an complete event.
For debugging I added some heavy trace() calls, which assumingly causes a slight delay, and voilà, it now crashes some lines further down in the code, still with "undefined" pointing a line in the code which is very unsuspicious. (once it was a call to invalidateDisplayList() in a component used for several years now without ever having made any problems)
Did anybody else encounter problems before when a large set of events is fired in very short time? What else can cause this strange "undefined" ?
Thanks as always.
I didn't work on this library but you can delay the event firing by using the magical setTimeout as following:
protected function dispatchProgressEvent():void {
setTimeout(function():void
{
dispatchEvent(OperationEvent.createProgressEvent(this));
}, 0);
}
This will delay the execution of the dispatchEvent until all current operations processed.
I have worked on the as3commons-async library. I don't have a definitive answer for you, I'm afraid, just my suspicion that this error isn't necessarily related to as3-async.
You describe similar weird happenings in other areas of the code base (even in Flex itself), so this kind of smells like either a Flex bug or maybe even a bug in the AIR runtime.
The only thing I can advice here is to create a test application that fires events in a similar fashion and speed (so, without using as3-async) to see whether you can re-create the errors.
If it does turn out to be a runtime issue, at least you'll have a solid testcase to send to Adobe.
I apologize for not being able to help you out concretely.
cheers,
Roland
Is it possible to inject data, for example a collection of assets (video, images...), in an swf at compile time?
We have a flex application that needs to be able to export an swf at runtime that contains all the necessary data, because it needs to run as a standalone application (on- and offline).
The idea so far was to create a server side script that calls the flex compiler and feed it the data it needs. This approach seems to work fine using the [Embed] tag for single files, but it gets kind of messy when trying to inject collections of data that vary in length for each exported swf.
We could generate an mxml file with one embedded variable for each asset and include it at compile time, but that approach seems for from ideal.
We've looked into some actionscript bytecode libraries, but those do not seem to be fit for this.
Any suggestions or other approaches for this kind of problem?
Thx,
Bert
[Embed] is definitely the way to go. You can generate an AS file that has lots of embeds. While the generated code might be a bit ugly, you can generate a nicer api too. For example, if you want an array, generate code like this:
[Embed(...)]
private var img_0:Class;
[Embed(...)]
private var img_1:Class;
[Embed(...)]
private var img_2:Class;
public var images:Array = [img_0, img_1, img_2];
That way the only ugliness is in private variables only the code generator will see. The public variable is an array.
I'm not sure why you need to do that but i guess i'll try to generate the needed actionscript file from template or something like that and then call the flex compiler.
Hope this helps you...
try as3swfit is able to generate an swf file from an empty ByteArrayand afaik it's possible to insert embedded graphics there
Like Sam said, [Embed] could work, but what are you trying to load? My first reaction is that recompiling for every request would be a big drag on the server.
Over the past three weeks, I have lost at least 120 man hours because of some lesser known functionality in ActionScript 3. One of the problems was that, with Internet Explorer, if there are too many messages sent through LocalConnections, it will slow the messages sent through, but in the standalone player and in Firefox, this threshold is significantly higher. Another was that the static values of a class are instantiated even if the member itself is not being used:
import path.to.FooClass;
private function thisIsNeverCalledButItEnsuresThatFooClassIsImported():void
{
var f:FooClass = new FooClass();
}
Since FooClass had a static reference to a Singleton, that Singleton was instantiated so when I loaded a Module which used that Singleton, it would bind to values in an unpredictable way.
Additional cases where things behave in an unexpected way:
MovieClip.addFrameScript
flash.trace.Trace as a class
int is a faster incrementer class, Number is faster for mathematics, and uint is incredibly slow.
PrintDataGrid, if it has only one page, needs to have an empty value appended to the end of its dataProvider
If you use try...catch around two LocalConnections and connect them to the same channel, you will force garbage collection without needing System.gc
So here's the question (and I'm sorry for omitting this in the original post), is there any consolidated documentation for this type of behavior anywhere? Is there any (even non-Adobe) documentation on these issues (websites, forums, books, ANYTHING)? I know that these things are definitely easy enough TO document, but has anyone done so?
If not, am I missing anything? Are there other issues which I should know about?
This kind of useful information is very often not "centralized". Moreover, what you are looking for is something related to the experience of the programmer (more than to official docs).
FYI, there are two other methods for ensuring a class is included.
#1 - This syntax is actually used in the Flex source code:
import path.to.FooClass; FooClass; // note double reference
public class References
{
// No references needed in this class
}
#2 - Use the includes command line argument
-includes path.to.FooClass
You can always submit your experience using the "feedback" section in the help. Unfortunately, this is less obvious than the link that used to be at the bottom of each page in the older help files (which also served the useful function of opening a browser window with the web version of that help page).
Adobe says that it incorporates the comments from previous versions of the help into new versions, but my own observation suggests that there are instances where it does not happen. However, that and the appropriate cookbook are still the best avenue for those who believe that this kind of information should be centralized.
Note that the whole purpose behind modules is to avoid compiling code multiple times, so importing FooClass kind of defeated the purpose. The problems you had in this instance are just one of the many that happen if you use Singletons, and it's unfortunate that the first official Framework, Cairngorm, encouraged their widespread use. Check out http://misko.hevery.com/2008/08/17/singletons-are-pathological-liars/ .