In the last days, I worked in a way to link Flash/Actionscript3.0 and C/C++ applications or libs. There are different ways to do it but each with its limitations.
1) Just code directly your Actionscript inspired in other C/C++ application or libs.
The main advantages of this method are: “it is your code”, you know how it works, you know how to improve it and is all Actionscript.
The main disadvantages are: the hard work used to code a “new” application and to keep the code updated with new algorithms.
2) Use the Adobe Alchemy. Alchemy is a tool that enables you to compile C/C++ code into ActionScript 3.0 as a SWF or SWC that runs on Adobe Flash Player 10 or Adobe AIR 1.5.
The main advantage is you do not have to code all from scratch like in 1).
The main disadvantages are: you have to adapt your C/C++ code in a way that Alchemy tool recognizes it, witch can be hard work for long applications or libs; if the C/C++ is not yours it is hard to keep the code updated and it only works on GNU environments (MAC OS, LINUX, Cygwin for Windows ).
Example: Some libs available by Adobe.
3)Use HTTP protocol. Since Actionscript is a Web-based language you can use the HTTP to communicate with other applications.
The main advantage is the easiness to code it and use it, there are a lot of examples in the Web, particular in Adobe Manuals, how to communicate via HTTP protocol using Actionscript.
The main disadvantages are: you need a HTTP server and the communication is quite limited (PUT/GET methods and security issues) .
4)Use a client-server socket architecture. This method is composed by a C/C++ socket server and a Flash/Actionscript socket client (or vice-versa, but you will need Adobe AIR for making an Actionscript socket server).
The main advantages are: you do not need any additional technique to compile and run your code(C/C++ or AS3), it is easy to keep your applications updated, you can send all kind of data (in the end, it is all about bytes) and if you are coding an desktop application (Adobe AIR style) you have no problems using “localhost” .
The main disadvantages are: you have a client-server network architecture with all limitations that are involved in the process (delays, security and firewalls, etc…).
NOTE: I will make some code available soon.
This is a tricky issue. When you have a Shape or a Sprite (AS3) object and you want to change its width or height (without using a transformation matrix), you can do it by changing the scale property (using percentage) or the width/height property (using pixel units). This second method will also change the scale, as you can read here, and both methods change the object coordinate system, as you can see here. Therefore, if you have used the graphics.moveTo(x,y) function, its parameters will also be modified according the new coordinate system. Due this scale change, the graphics will NOT move to a point that has (global) coordinates (x,y), but will move to a point with (global) coordinates multiplied by the scale value (x*scaleX,y*scaleY).
Example (you should understand first how flash coordinate systems works):
var myobject:Sprite = new Sprite();
myobject.x = 0;
myobject.y = 0;
myobject.scaleX = 2; // or myobject.width = myobject.width * 2;
After this change, the graphics of myobject instead of moving to the point (10,10) in the global system, will move to the point (20,10). The X (global) coordinate was multiplied by the value of myobject.scaleX .
If you think, this is how flash coordinate system works in general. The difference is in the scale properties, which have by default the value of 1. Therefore, any coordinates (X,Y) multiplied by the scale (1,1), will result in the same values (X,Y). But if you change the scale value, the coordinates (X,Y) will also change.