(1)When I run the HTTPService code in Flex builder and use Ctrl F11 to run the application then the HttepService runs fine and returns the value. Here, it is run inside an html wrapper 'mypath\Learning\bin-debug\httpServiceissue.html'
(2)The same code when I compile through command-line and then run in Flash PLayer then it won't run. This time its running on its own without html wrapper around.
Also, setting '-use-network = false' in command line (2 approach) allows flash player to load this file. I know that setting flag false will restrict SWF's access to local machine (no network) and give it access to local resource, but then why it works in Flex builder inside the html wrapper (in 1 case).
Please share you opinion on this.
'mx:HTTPService id="rooms" url="myfile.txt" fault="httpFaultHandler(event)" resultFormat="e4x" result="httpResultHandler(event)"'
I'm not really sure, I've never tried to use the service in that way. It might be a security, or "sandbox" restriction, that unless you've got a "crossdomain.xml" you can't get to any resource that isn't in the same domain. Would the txt file be delivered by some kind of web server when you hit F11?
Good luck, please let us know when you find an answer.
Related
i have been working on a Photoshop UI project and also working with Flash Builder for about 3 weeks and i can't find a solution to a communication problem. Here are some details about the issue; if you are interested in helping me, thanks.
The main frame of the UI is Extendscript
I have an as3 swf which needs to load a local JPG file dynamicly, I
assume this is a "Access Local Files Only" situation for Flash.
The same SWF needs to communicate with Extendscript, so i load it into
a FLEX app dynamicly via SWFLoader and it passes some variables to,
and triggers some functions in FLEX via a "myFlexParent" object.
Flex is the bridge between Flash and Extendscript so it passes the
variables and functions to Extendscript JSX code via
Externalinterface.call or CSXSInterface.instance.evalScript().
This is where i'm STUCK. I guess ExternalInterface calls or CSXSInterface.instance.evalScript() are threated as a network operation and they don't work if i set the compile option "-use-network=false" in flex. Bu otherwise the local JPG file cannot be loaded.
Adding locations in the Settings Manager wont work for me because i'm going to turn the UI into an Extension and it should be easy to install.
I guess i'm trying to find a way to establish 2 way communication between FLEX and ExtendScript, that would be interpreted by flash player as a LOCAL communication, which actually is.
I'll appreciate any bit of information. Thanks.
ExternalInterface is going to be considered a network call and setting the -use-network=false will break those calls down. This is due to the security sandbox. If it was allowed then the flash app could be used with some simple AJAX to turn a non-network app into a network app very easily.
Adobe doc's say:
This communication relies on the domain-based security restrictions
that the allowScriptAccess and allowNetworking properties define. You
set the values of the allowScriptAccess and allowNetworking properties
in the SWF file’s wrapper.
Reference link:
http://help.adobe.com/en_US/flex/using/WS2db454920e96a9e51e63e3d11c0bf6167e-7fff.html#WS2db454920e96a9e51e63e3d11c0bf6167e-7ff5
Look into changing your app into an AIR app as you will be able to do both network and local file operations (different security model since the user installs the application).
I am writing a Qt application that calls QProcess::startDetached("wscript.exe script.vbs") to show the delete confirmation dialog in Windows.
this is the script:
Set objShell = CreateObject("Shell.Application")
Set objFolder = objShell.Namespace("-")
Set objFolderItem = objFolder.ParseName("-")
objFolderItem.InvokeVerb("Delete")
the arguments for Namespace and ParseName are from the arguments passed to the script.
This may be inefficient because it opens an external application first before running the script. I was wondering if i can run VBScripts in a Qt application.
If not, what alternatives can i do?
My VBScript is very weak, so I'm not 100% sure I understand what you are trying to do. My assumption is that you are trying to delete a folder, but want to give the user the normal confirmation box and animation while the action is occurring. If that is not correct, please let me know and I will remove this answer.
A few ideas:
You could call the Windows API directory within your C++ code to do this. I believe the correct call would be to use IFileOperation (Vista and later) or SHFileOperation (pre-Vista)
Qt already has message box dialogs. Although you might not get the exact same functionality as the native shell, you could use this (QMessageBox::warning) and then delete the folder using QDir. This would also be cross-platform portable.
If you stick with the VBScript, I doubt you would see any performance issues unless this is being called many, many times in a loop or something. You know, the old "premature optimization is the root of all evil" thing.
You should read up on the IActiveScript COM interface. You can create an instance of an interpreter that implements IActiveScript to provide a runtime for evaluating scripts. VBScript and JScript can both be used for this and a number of other third-party scripting languages also provide IActiveScript support.
The overview for working with this is you create a language runtime (an instance of VBScript for instance) then add some custom objects to it. Typically if you are embedding an interpreter into your application then exposing an Application object is a good place to start. This can be just an IDispatch interface or something more concrete with an IDL generated typelibrary and all the trimmings. Once you have added the necessary named items into the runtime you load one or more scripts. Any public functions or subroutines declared in the scripts now get exposed via the IDispatch interface of the live runtime once you switch its state to active or running. To actually run the script program, I invoke the Main function for my stuff - you could choose some other scheme as applicable to your environment.
The nice thing about ActiveScripting, is to change language you just change the runtime CLSID. So if people prefer Perl they can use PerlScript or PythonScript etc. Your Application object remains the same hence you don't have to write additional code to support the new languages. The only requirement is that everything is COM.
I'd like to be able to write a .swf file that is runnable as a command line app. In other words, I would be able to create actionscript classes which can interact with stdin and stdout, and could then execute that .swf directly in the command line.
I suspect that this isn't really possible. Can anyone confirm that?
EDIT:
A couple of the answers pointed out that using Flash for command line work probably isn't the best choice. I wholeheartedly agree in most situations. The reason I am asking about this is because I want to do some AS3 code generation, and reflecting on AS3 classes within the runtime would be easier than parsing the code or walking the intermediary XML that asdoc produces. I'm doing the XML approach now in Ruby, but would love to have a cleaner solution!
YES! It actually is possible.
You can create a pure AS3 AIR project (without any application window) and run from the command line using ADL (AIR Debug Launcher).
ADL will execute your SWF and will pass whatever arguments you give it directly to your application at runtime—all from the command line! To read the arguments from AS3 just add this code to your main class:
package
{
import flash.desktop.NativeApplication;
import flash.display.Sprite;
import flash.events.InvokeEvent;
public class CmdLine extends Sprite
{
public function CmdLine()
{
NativeApplication.nativeApplication.addEventListener(
InvokeEvent.INVOKE, onInvokeEvent);
function onInvokeEvent(invocation:InvokeEvent):void {
trace(invocation.arguments);
}
}
}
}
Your main class will still extend Sprite, but you won't see any UI unless you create NativeWindow objects. If you're using Flash Builder, just create a new AIR project and rename the extension of the main .mxml file to .as (before you finish the wizard).
Here is more about ADL: Using the AIR Debug Launcher (ADL)
Also, this will be very useful: AIR application invocation and termination
You can do all your output using trace(), write files, or even write directly to stdout, as seen here.
Apparently there is the Tamarin project which aims to create an open source implementation of AS3. This page gives a little detail of compiling an AS3 script and running it from a command line.
I'm not getting a good idea of how stable Tamarin is, but it might be your best bet for now. On the other hand, I have to strongly agree with #zenazn that you would be better off long-term learning a language more designed for general purposes, but if really want to just use Actionscript, don't let anyone stop you :)
There's no way to do this with a bare SWF right now.
However, you can publish your Flash content as an AIR app. The app can then be invoked from the command line, and you can collect the arguments from the arguments property of an InvokeEvent. The basic idea looks like this:
NativeApplication.nativeApplication.addEventListener(
InvokeEvent.INVOKE, onInvoke );
// ...
function onInvoke( e:InvokeEvent ) {
var numArguments:int = e.arguments.length;
// ...
}
Note, however, that this is essentially a one-way street. You can grab the command-line arguments, but Flash still doesn't grok the idea of stdin and stdout.
Actually, there is a project that makes it possible. RedTamarin is a project that extends AS3 (technically, the Tamarin project which is the Adobe/Mozilla ECMAScript project) to have access to low-level libraries (ie. POSIX). In its current state it appears to be good for stuff like shell-scripting-like programs which is what it sounds like what you're looking for.
Give it a try:
http://code.google.com/p/redtamarin/
You can interact with stdin, stdout and stderr with redtamarin
http://code.google.com/p/redtamarin/
see examples/docs here
http://code.google.com/p/redtamarin/wiki/System#stdout
http://code.google.com/p/redtamarin/wiki/System#stderr
http://code.google.com/p/redtamarin/wiki/System#stdin
there is a difference between Flash and ActionScript 3
Flash is a runtime, AS3 is a language
I don't see why AS3 would not be a good programming language
for the command line and/or the server side
Now, redtamarin is just that, a runtime that allow you to
run your AS3 source code on the command line.
Also, depending on your needs, you can use it in different ways
to run script on the command line
$ ./redshell myscript.as
run ABC or SWF files on the command line
$ ./redshell myscript.abc
$ ./redshell myscript.swf
run an exectuable
$ ./myscript
When you will run an AS3 script it will be dynamically interpreted,
using ASC you will be able to compile this same script to an ABC file
that can also be run from the command line.
If for example you need to assemble numerous ABC files together,
you can use swfmake to merge them into SWF file and the runtime
will run that SWF file too from the command line.
Finally, if you need to bundle everything in one executable,
you can use createprojector to take your ABC or SWF file
and merge it with the runtime itself to obtain an independent
executable.
Redtamarin provide native API that cover file system access,
sockets, operating system info, etc.
Now it is possible with AIR 2.0. Check this article to start.
If you are really that inclined, you could open a local socket, and then have a helper program, running from the command-line communicate with the open SWF.
This might be a good time to learn another language. May I suggest Java?
I had a similar question recently. It took me a few days to answer it for myself, but you can create a .swf and execute it entirely from the command line.
AS3 Filesystem Hello World
You could have a look at Haxe with is very similar to AS3 and could compile NekoVM Bytecode, which could be run on the command line.
Also interesting could be HippoHX, it is a kind of framework to create desktop applications out of flash movies. (similar to AIR, but with full access to the system.)
Nope--not possible. The best you can do is a standalone app (which can be made in Flash or with a Projector version of flash player, available from the Adobe website).
And why would you want to--Flash is awesome because of the great GUI capabilities. There are plenty of other programming languages that are much better suited for the command line (Python or Ruby or, god forbid, even Perl)
I'm sure there's a simple explanation for this, but I haven't had much luck at finding the answer yet, so I figured I'd put the word out to my colleagues, as I'm sure some of you've run into this one before.
In my (simple) dev environment, I'm working with a handful of WCF Web Services, imported into my FB3 project and targeting a local instance of the ASP.NET development Web server. All good, no problems -- but what I'd like to know now is, What's the right way to deploy this project to test, staging and production environments? If my imported proxies all point, say, to http://localhost:1234/service.svc (from which their WSDLs were imported), and all I'm deploying is a compiled SWF, does Flex Builder expect me to "Manage Web Services > Delete", "> Add", recompile and release ever time I want to move my compiled Flex project from development to test, and to staging, and ultimately into production? Is there a simpler workflow for this?
Thanks in advance -- hope my question was clear.
Cheers,
Chris
If you have path names which will change depending on the enviroment then you will likely need to recompile for each environment since these will be compiled in the swf.
I typically use ANT scripts to handle my compile/deployment process when moving from development and production environments. This gives me the ability to dynamically change any path names during the compile. These build files can be integrated into Flex Builder making this process very easy once you have everything set up, and can be done with one click or scheduled.
Thanks Brett. I've been meaning to dig into automating my build processes anyway, so now's probably as good a time as any. :)
You do not need to build a SWF for each environment. Here's a technique I use commonly:
Externalize your configuration properties into an XML file; in this case, it could be a URL for each service or a base URL used by all your services
When the application starts up, make an HTTPService call to load the XML file, parse it, and store your properties onto some bindable "configuration object"
Bind the values from that object against your objects that depend on the URLs
Dispatch an event that indicates your configuration is complete. If you have some kind of singleton event dispatcher used by some components in your app, use that, so that the notification is global
Now proceed with the rest of the initialization of your application
It takes a little work to orchestrate your app such that certain parts won't initialize until steps 1-5 take place. However I think it's good practice to handle a lot of this initialization explicitly rather than in constructors or various initialize or creationComplete events for components. You may need to reinitialize things when a user logs out and a different user logs in; if you already have your app set up to that initialization is something you can control then reinitialization will not be a problem.
When an ASP.NET application errors out and generates the yellow-screen display, I'd like to create some kind of link from the error page which would jump directly to the correct line of code in Visual Studio.
I'm not sure how to approach this, or if there are any tools already in existence which accomplish it - but I'd love some feedback on where to start.
In the event that generating a new error page is necessary, is it possible to replace the standard yellow screen across an entire webserver, rather than having to configure the customized error output for each application?
You would probably need to embed an ActiveX control in the page for something like that to be possible.
The yellow screen of death is served by the default ASP.NET HTTPHandler.
In order to intercept it, you would need to add another HTTPHandler in front of it that intercepts all uncaught exceptions.
At that point, you could do whatever you want for your error layout.
Creating a way to directly jump to Visual Studio would be tricky. I could see it done in IE via a COM/ActiveX object.
The yellow screen of death is just a 500 error as far as the server is concerned, you can redirect to a custom screen using the error section of the web.config. To make a whole server change in the same manner you could probably override it at the iis level? Or perhaps even set the default behaviour in the machine.config file (not 100% sure about that one though)
The yellow screen of death is just a 500 error as far as the server is concerned, you can redirect to a custom screen using the error section of the web.config. To make a whole server change in the same manner you could probably override it at the iis level? Or perhaps even set the default behaviour in the machine.config file (not 100% sure about that one though)
If you let it bubble up all the way to IIS you will not have any way to access the Exception information. Its better to catch the Exception before the YSOD and serve your own.
This can be done at the application level.
Don't forget that you need the Program Debug Database (pdb) file to find the source code line number. An application in release mode won't have the same level of information as a debug release.
The easiest, laziest thing I could think of would be to have the process happen thusly:
The yellow screen is modified so the line is source code is clickable. When clicked it delivers a small text file with the source file name and line number.
A small program on the PC is tied to the extension of the small file the yellow screen let you download. The program uses visual studio's extensibility model to open the source file and goto that line. The program may need to know where your source code is.
A simple Google search
gives helpful pointers on how to manipulate VS with an external program such as this post on MSDN.
If you want to go snazzier, then there are certainly other methods, but I'd rather write out a quick and dirty program, and get it out of my way so I can be about my business.
Don't let the tools become projects...
-Adam