I have a customer requirement where they would like to have different windows of a web application on 2 different displays (monitors): data lookup and entry on one screen and a document viewer on the other. The document viewer will be Flash or Silverlight based and loaded in a webpage. The app will be at least partially based on SharePoint. There is a need for communication between the two windows: when for instance a new task is clicked in the "data" view, the accompanying document needs to be opened in the other one.
The difficulties as far as I can determine:
Opening the two windows from within a web app
Actively position the windows on the 2 displays
communication between the two windows
as robust a solution as possible from a user perspective (e.g., re-opening a closed window, tracking changes between them, etc.)
I am looking for pointers in getting this done. I understand that I can launch the second window from Javascript, but that does not give me a lot of control over it. This solution will run in a closed, controlled environment, so limiting the solution to a specific browser (preferably IE8+) or the need to install additional software/components is no problem.
If i were you i would implement this with silverlight and asp.net mvc.
create a state object which describes the state of the 2 windows, this can be consumed and updated by both the silverlight app via web services, and the mvc app via javascript, postbacks or web services.
Related
Just a general question: is it possible to display & interact with a Shiny-generated html page with charts, dropdown menus and other elements, within a Qt application? I've browsed at some documentation and videos for QtWebKit and WebView, and while mentions of basic html display are covered, I'm just wondering about more-involved uses.
The R code which I have on a VPS displays the Shiny app in html already, and is accessed via direct URL.
It depends on what you mean by "interact": who does the interaction?
A human user interacts directly with the page - that's the easy case. Use the web view.
Qt bundles a complete Chromium web engine. Anything Chrome can do, so can Qt's web view. As long as your page works in the Chrome version that uses the same Chromium version as Qt does, it will be fine in Qt's web view.
Your code interacts with the page - that's more involved. You'll have to add a remote control channel working on top of websockets to interact with the page. It could be as simple as the Qt application sending javascript to execute on the page, and receiving back the json-serialized results. That gives you the most power at the lowest implementation cost (a few dozen lines of javascript and C++).
We've an existing application developed in VB 6. There are 6 - 8 modules available. In main screen, a separate button is available for each module, which on click will load the respective modules. We're in the process of migrating this to a web-enabled system and identified to go with Java-based solution.
Now instead of completely developing and migrating to Java platform, we're doing a technical feasibility study of migrating module-wise. That is, on click of 'Module 1', for example, will open up a browser instead of existing VB application forms and all subsequent handling/processing/loading/saving will be handled by the web-based Java application, which actually runs on a web/app server. Slowly this will be migrated for other modules also.
My question is, is this technically possible/feasible? That is, can we open up a browser on click of a button and direct all subsequent requests, sessions, cookies to the Java application running on web/app server. Any pointers/suggestions/thoughts towards this are really appreciated.
NOTE: I heard about WinINet API from my friends which enables to interact with HTTP protocols.
If you are moving to the "poor client" (Web) model then your back end will be creating 100% of the user interface as Web pages.
In such a case your existing rich client needs to be dumbed down. There is no point in trying to request the HTML from the server and reinterpreting it into a rich user interface written in VB6.
Thus you don't need to worry about the WinInet API (which you wouldn't need anyway since from Win2K onward you have at least 3 very nice wrapper ActiveX controls and classes at your disposal: the Internet Transfer Control, the XmlHttpRequest class, and the WinHttpRequest class).
No, in your case you will probably be stuck with replacing your "modules" (???) which probably means Forms (?) by a Form hosting a WebBrowser control.
However it will be clumsy to integrate what goes on in there with your other "modules." If that's needed you're going to probably need to spelunk the WebBrowser DOM to fish out data, inject data, etc.
Ideally you'd be moving to a Web Service model instead of a Web model. This opens a world of front end possibilities (Web, mobile, rich client) without the need for multiple back ends and is quite usable in VB6. Things have even gotten easier over time as SOAP is abandoned in favor of simpler, loosely-coupled RESTful Web Services.
What you have described is feasible to a degree, but when you start adding requirements like session cookie control it might get ugly. You may end up needing two logons in your program, one for the old/existing parts and another for the browser-based parts.
You might be better off just letting part go over to a browser and strip parts out of the old app and make people run both side by side.
I realize that this question can start a discussion but that's really not my intention. We've created a Flex Application to take tests from candidates. The advantage of the Flex Application is that all state can be stored in the application running in the browser of the client. Things like time limits, navigation, scoring, ... can all be handled within the application without us having to worry about a back button for instance. Even running the app offline with Adobe Air isn't that hard.
My question now is if such an application could easily be made with HTML, Javascript, Ajax, ... ? The reason I'm asking is because an application in HTML would be much easier to distribute on Mobile devices for instance. Also, our domain model for instance is mostly implemented in AS3 (Flex) so using it along the server side means porting it to C#.NET. (with two codebases as a result).
Look at any good MVC toolkit, you will easily be able to handle this. Castle project is good as is Microsoft MVC, both of which allow you to choose from a variety of view engines to handle the actual page rendering thereby allowing you to choose the most 'mobile efficient' engine...
As for the technicalities, you would store all persistent data in a server session object.
I'm tasked with writing an application for placing and connecting objects (sort of like a room planner where you can place furniture). I've made a demo using Flash Builder 4 and built it for AIR as a desktop app. Now the client wants the full app, but they and I am unsure whether to continue building it as an AIR app or transform it to a web application using Flex. I tried making a simple conversion of the AIR app to a web app, and most things worked but not all. The things that don't work seem to be simple bugs, though, not complete lack of capability.
The capabilities that I'm going to need (except for the modelling) are:
Printing of the finished image + a list of the furniture that has been placed
A way to save and retrieve finished plans
A way to export the list of furniture to Excel format
Handling a whole slew of data about the different objects
Only the printing has been implemented so far, and seems to work in the web app as well.
What advantages/disadvantages are there with the two approaches? Are any of the capabilities I need much worse (or even impossible) to implement in either approach?
Edit: Thanks all for your answers. From them, and my own research, I came up with the following:
Web app
Advantages
Accessible, no need for installing software
Easy to keep up to date
Disadvantages
Requires Flash 10 (for saving files)
Requires a web server to serve content
Sligthly longer development time (from where I am right now)
Requires an internet connection to work
Lots of data transport, may be slow on a slow network
Desktop AIR app
Advantages
Slightly faster development time (from where I am right now)
No web server necessary
Can be used while not connected to the internet
All data is local and faster to load
Disadvantages
Requires the Adobe AIR runtime + a separate installation of the program
Updates need to be distributed to all users and an admin needs to install them
There is no one straight answer for this one. A few points to consider:
If you want to use specific AIR features like offline usage, integration with the user's OS etc, you should use AIR (of course)
Flex applications are more easy to distribute and upgrade, because everyone uses the same swf instance from the server. When using a server backend with AIR, you should be aware of possible backwards compatibility issues when upgrading you application.
There are a lot of little differences, but in broad strokes, the only considerations you have to think about are:
Does it need to be on the Web?
Does it need file system access.
If (1) then use regular Flash. If (2) then use AIR.
The biggest disadvantage is related to the update model - you need to be a super user in order to update the air application - especially in enterprise the users of the AIR applications don't have rights to update it. If your application is running in the browser you do not have this issue.
Besides that, I do not see any disadvantage.
Check out flash 10 FileReference you can let users save results easily to their local file system. I've used it to create PDF's and let the user save that for printing.
For the PDF side I used Alive PDF.
protected function PrintCard(event:MouseEvent):void
{
//ShowHideBorders();
var printPDF:PDF = new PDF( Orientation.LANDSCAPE, Unit.MM, Size.LETTER );
printPDF.setDisplayMode( Display.FULL_WIDTH, Layout.SINGLE_PAGE );
printPDF.addPage();
printPDF.addImage(CardPanel);
var fileRef:FileReference = new FileReference();
fileRef.save(printPDF.save(Method.LOCAL), "card.pdf"); // Sends the file to the USER
//ShowHideBorders();
}
I have a problem where a Web Application needs to (after interaction from the user via Javascript)
1) open a Windows Forms Application
2) send a parameter to the app (e.g. an ID)
Correspondingly, the Windows Forms Application should be able to
1) send parameters back to the Web Application (updating the URL is ok)
2) open the Web App in a new brower, if it does not exist
If many browser windows are open it's important that the correct one is updated.
Windows Forms Application is in ASP.NET
Browser is IE6+
The applications are controlled and internal for a specific organisation so it's not a question of launching a custom app.
Question A) Is this possible?
Question B) How do I send parameters to an open Windows Forms Application from a Web App?
Question C) If updating the Web App, how do I make sure the right browser is targeted?
What you're asking for is possible but seems awkward.
Trying to call an application from a web page is not something you could do due to security considerations. You could however make a desktop application which would be associated with a certain type of files and then use content-type on the web page to make sure that your app is called when a URL with this type is opened. It would be similar to the way MS Office handles .doc or .xls documents or the Media Player opens the .mp3 or .wmv files.
The second part (opening a particular web page from your application) is easier.
As you should know the address of your web page create a URL string with the parameters you want and open it in default browser (there are plenty of examples on how to do that, a sample is below).
System.Diagnostics.Process.Start("http://example.com?key=value");
If you want to update the page in the already opened browser or use a browser of your choice (i.e. always IE6 instead of Opera or Chrome) then you'll have to do some homework but it's still quite easy.
PokeIn library connects you desktop application to your web application in real time/per user. Moreover, due to its reverse ajax state management, you could consider both of your applications as one.
Check out
http://msdn.microsoft.com/en-us/library/8c6yea83(VS.85).aspx
Using VBScript in your Web Page you can call an open Windows Forms application and send keys to it.
This only works on IE though and you need to adjust the security settings to allow ActiveX.
Have a look into "registered protocols" (for example here and here). I know Skype does this to make outward phone calls from a web page. But probably some changes will be needed in the win application to intercept the parameters from the url.
I haven't tried this but it should be possible
No I don't think it's possible.
Think of viruses/trojans/spyware. If it were possible to launch an application from a mere HTML page, it would be very easy to install malware.
Browsers are designed to prevent you from doing that.
You could use clickonce to deploy and start the forms app - this should take care of sending the parameter to the app.
While this may not perfectly fit with your application, what about using a web service and the form?
Also, you can pass parameters to ensure IE6, not Firefox opens.
System.Diagnostics.Process.Start("c:\ie6\ie6.exe http://www.example.com/mypage");
Ok, so I actually found a clue to the web -> winform part.
The following code was handed to me from an web application that sends a parameter to a winform app. I assume this solution has some security factors in play (such as allowing running VBScript (and ActiveX?) in the webpage. That's ok for me though.
The code:
<script type="text/vbscript" language="vbscript">
<!--
Function OpenWinformApp(chSocialSecurityNumber)
Dim oWinformAppWebStart
Set oWinformAppWebStart = CreateObject("WinformAppWebStart.CWinformAppWebStart")
oWinformAppWebStart.OpenPersonForm CStr(chSocialSecurityNumber)
End Function
-->
</script>