I want to have my app which is minimized to capture data selected in another app's window when the hot key is pressed. My app definitely doesn't have the focus. Additionally when the hot key is pressed I want to present a fading popup (Outlook style) so my app never gets focus.
At a minimum I want to capture the Window name, Process ID and the selected data. The app which has focus is not my application?
I know one option is to sniff the Clipboard, but are there any other solutions.
This is to audit the rate of data-entry in to another system of which I have no control. It is a mainframe emulation client program(attachmate aka java-hosted telnet with 3250 support).
The plan is
complete data entry in Application X.
Select a certain section of the screen in App X which is proof of data entry (transaction ID).
Press the Magic Hotkey, which then 'sends' the selection to my App.
From System.environment or system.Threading I can find the Windows logon.
Similiarly I can also capture the time.
All the data will be logged to SQL.
Once Complete show Outlook style pop up saying the data entry has been logged.
Any thoughts.
Hooking the keyboard/mouse & screen scraping is pretty much the limit of what you can do with an applet. Remember Java is compiled to bytecode and run in the JVM. Because of the nature of the JVM, portability, and security concerns, you don't really have access to anything inside of the applet. All you will probably see from .Net is a "SunAwtFrame" classed window with no children.
The focus thing is doable, just use SendMessage (& other) API's to do what you need in the background and as long as you don't change the focus it will remain as is (ie. running code does not require focus)
As far as the data extraction goes, its going to come down to whether or not you can pull that info from the screen using some (potentially hardcore) image processing. Applets are a sort of no-mans land (from within .Net atleast), there is no JavaWindow.Textbox.GetAStringForMePlease().
For the record, there is an exception, if you physically control the applet. In that case you can make a sort of applet shell to hook the guts of the applet.
It sounds like you need to set up a global keyboard hook to capture the hot key this code project article shows how to do that (in C# but it's not much different):
http://www.codeproject.com/KB/cs/globalhook.aspx
And then you could use the FindWindow API to find the other apps window, then find the control that contains the "transaction ID" and use the WM_GETTEXT message to copy the text from it.
Related
I'm developing an application to run in background. This application is used to capture user’s activity on their system. Application is working very fine.
Now, I need to display a windows form over locked screen. Just like this:
Can any one help me! How can I show any windows form over locked screen?
Not possible, for security reasons no application should be shown when the screen is locked.
The only thing remotely similiar might be a Kiosk App:
Is the Windows.ApplicationModel.LockScreen namespace available for non-kiosk use?
There are a few different things here that are probably confusing things. unfortunately they are not very common scenarios so documentation is lacking.
You can use the Windows.ApplicationModel.LockScreen namespace for customising the display of the lock screen. This can be used to change the wallpaper or notification counts. It is probably the most common form of lock screen customization as it can be done by any app.
You can also use the functionality in this namespace to create an alternative lock screen. This could have different behaviour to the process of swipe up and enter password/PIN or Microsoft Hello face detection.
Creating such an app and distributing through the store requires extra permissions than 3rd party developers typically have.
"Kiosk mode" apps are created as apps that run above the lock screen. Such apps have no real connection to lock screen replacements but are related in their use of similar underlying elements of the OS.
In terms of what you are trying to achieve, it sounds like you should be able to do this by declaring the windows.lockScreen extension and then using LockApplicationHost to do the actual unlocking. As mentioned above the lack of a way for 3rd parties to distribute such apps through the store means there is a lack of documentation in this area but it should be possible.
One thing to take note of in such an app is an under even greater memory/resource constraints than a typical app and so you should keep this in mind during your planning and development.
I know this is an old question but for anyone still looking:
It is a security risk don't do it.
If you still want to do it this could help: SampleHardwareEventCredentialprovider
You will have to play with WinAPI and CredentialProviders but it is working demo and will show simple windows dialog with a button at lockscreen
I want a automatic update notification in my application. A message box should appear which tells that an update is available, if user wants then it can download the latest version in downloads folder of windows. Nothing else (user will install it manually) not application.
-I'm using Installshield so no Click once solution.
Thanks
If you want an out-of-the-box solution to this problem you're likely to be disappointed. I haven't found anything that works except ClickOnce, and I dislike it. I did find this:
http://windowsclient.net/articles/appupdater.aspx
My solution was to roll my own. It's actually not that difficult. I wrote a small bootstrapper application that first checks for updates, downloads them if necessary, and then launches my application in a new AppDomain. Pretty easy.
If you want to check for updates while your app is running, you need to write and add a component/class to your project that performs that task, and informs the user (MessageBox or whatever) that an update is available. If they choose to perform the update then you need to launch your bootstrapper (so it can fetch the updates) and kill your current process.
All of this is very possible with a little time and some custom code. It's not as difficult as it sounds. The biggest thing is determining how configurable you want your custom solution to be because that can affect when/where your bootstrapper goes to look for updates (I built mine to look for updates on a network share).
http://autoupdatewpf.codeplex.com/
i found one. This one is quite simple and solve the purpose.
I have a very critial business application presently running using Winforms.
The application is a very core UI shell. It accepts input data, calls a webservice on my server to do the computation, displays the results on the winforms app and finally send a print stream to the printer.
Presently the application is deployed using Click-once.
Moving forward, I am trying to contemplate wheather I should move the application into a Silverlight application. Couple of reasons I am thinking silverlight.
Gives clients the feel that it is a cloud based solution.
Can be accessed from any PC. While the clickonce app is able to do this as well, they have to install an app, and when updates are available they have to click "Yes" to update.
The application presently has a drop down list of customers, this list has expanded to over 3000 records. Scrolling through the list is very painful. With Silverlight I am thinking of the auto complete ability.
Out of the browser - this will be handy for those users who use the app daily.
I haven't used Silverlight previous hence looking for some expert advice on a few things:
Printing - does silverlight allow sending raw print data to the printer. The application prints to a Zebra Thermal label printer. I have to send raw bytes to the printer with the commands. Can this be done with SL, or will it always prompt the "Print" dialog?
Out of browser - when SL apps are installed as out of browser, how to updates come through, does the app update automatically or is the user prompted to opt for update?
Printing -- using the PrintDocument API your user will be prompted for a print dialog. Currently using that API there is no way to suppress this. It isn't ideal for high-volume thermal situations (like pharmacies, shipping warehouses, etc.). You could use the trusted application mode and peek out into COM and do whatever you want with the printer.
The update happens when the application asks for it. There is an API to use and, once called, if an update exists it is downloaded -- no prompt to the user as an option. If an update is found you can alert the user to restart or that on the next restart they will have the updated application.
Autocomplete is not something that can only be done in Silverlight. Your ClickOnce app is already out-of-browser. And printing via raw bytes to a thermal printer is something that would not be easily engineered in Silverlight.
Not trying to sound negative, but in sum it sounds like you're better off simply working on enhancing the app that you already have.
I am currently running a SL3 project where we are in a highly iterative development mode with about 25 active test customers. I am making small changes at a clip of about 4 new builds per day. It is important to know this application is mission critical line of business for these 25 people, it is the tool they use all day to do their work so they are using it constantly and often launch their browser and the app in the morning and never close it until the end of the day.
The challenge is that when I make an update to the application I have no clean way to notify the users, in most cases this is ok as it is rare that I introduce a data contract change or something that would be a classic 'breaking' change to the app/service. Users keep plugging along and will get the change next time they refresh.
Right now we have resorted to emailing everyone and telling them to force refresh or close the browser and log back in.
Surely there is a better way...
Right now my train of thought is to have a method on the server that compares client xap versions and determines if the client being used is the most up to date, if so I will notify the user and make them update.
What have you done to solve this problem?
One way of doing it is to use a push mechanism (I used Kaazing Websoocket Gateway but any would do). When a new version of the XAP is released a message (either manually entered into the system by admin or automated triggered by XAP file change event) would be sent to all the clients. In the simplest scenario some notification would be shown to a user (telling him that a new version is released and the application needs to refresh) and then the app would refresh (by simply reloading the page) saving user's state if necessary.
If I would do this I would just keep it simple. A configuration value in web.config and a corresponding service method that simply returns that value (the value itself could be anything, but a counter is probably wise). Then you could have your Silverlight app poll that service method at regular intervals. Whenever the value changes (which you would do manually when you deploy a new version), just pop up a dialog telling the user to refresh the browser or log in/out. This way you don't have to force them to refresh every time. If you go with the idea of comparing xap file versions they will always be required to refresh, even for non-breaking changes.
If you want to take it further you could come up with some sort of mechanism to distinguish between different severity levels. For instance, if the new config value would contain the string "update_forced", you could force the users to reload the app by logging them out automatically (a little harsh, perhaps). If it contains the string "update_recommended", just show a little icon at the top right corner saying that there is a new version and that they should upgrade in their own time.
Granted, this was targeted at Silverlight 3, but with the PollingDuplex client and such in the newer versions of Silverlight, you could publish an "Update Now" bit to the clients, and build a mechanism in the client to alert the user that there is an update that is now out... that they should update it shortly, etc. You may even be able, through serialization and such, to save the state that they are in when they close the app to reload it.
We've done stuff similar with a LOB app that we built, so that as users are changing things, the rest of the userbase sees those changes immediately. Next up will be putting the flags in to change authorization and upgrades "on the fly" if you will.
What are my options for printing in Silverlight 3? Assume I have this awesome Silverlight application/control that creates a graphical display of some data. Now the user wants to print it.
I have considered a few options but I have yet to test any of these. Before I do that I would like to get some feedback on how it can be done.
Use the browser printing capabilites. In my experience this is does not provide a useful print, but perhaps with some interaction between the Silverlight host and the browser it can be done?
Use WriteableBitmap. The image can either be written locally, but this requires interaction from the user, or sent to the server where a suitable file (e.g. PDF file) can be generated and then sent back to the browser. Unfortunately you now get the overhead of sending the image twice across the network and increased complexity on the server side.
Send XAML back to the server that is then rendered in a WPF application running on the server. The result is the sent back to the client. I'm not sure if this is possible at all however, but if it is the network overhead is less than in option 2. Unfortunately, the complexity on the server side is even higher.
Wait for Silverlight 4?
One thing I have considered is that my awesome control probably will have a ScrollViewer at the highest level, but the user will want to print the entire content of the control, not just whatever is visible inside the bounds of the ScrollViewer. How can I handle this added complexity?
In all seriousness, I think your best option is to wait until Silverlight 4 if your client can wait that long. I've seen a good bit of buzz about SL 4 supporting printing on twitter, though it's not official. I'd wait until PDC in a few weeks and see if any Silverlight bits trickle out to support printing.
Take a look at SmartPrint for Silverlight 3: http://www.smartwebcontrols.com/SmartPrintDetails.aspx
TBH I wouldn't use any of those options:-
Printing from the browser. Fine if you are printing say a chart or something else that scales well on a single sheet of paper. Rubbish for anything else especially where you have scrolled content.
WriteableBitmap. I can't see a client-side only solution being acceptable to the user "Please save this and then print it" message. It could be made to work bouncing off the server but would be bad for bandwidth use (bandwidth is import right? because in a well-connect intranet you wouldn't using Silverlight?).
Sending XAML to server for rendering. Really awkward it would be WPF XAML not SL XAML, where and how would you do the binding, why send XAML at all, since the server needs to be pretty much clued in on this so why can't it hold the XAML needed as well. Or were you thinking of sending just pure XAML with all the data needed? Still its a lot of plumbing needed in the SL that isn't actually related to SL.
Use Silverlight 4, its possible that in the not to distant future this would be the correct no-brainer choice (personally I wouldn't hold my breath) but right now SL4 doesn't exist.
A 5th option
Place report generating code on the server and have the Silverlight app inform the server of the data set required (not necessarily posting the data merely the criteria needed to access the correct set). In my experience direct prints of GUIs aren't particularly satisfactory when the user really needs a good printed form of the data.
Its true that at times the user just wants to quickly get some offline access to a grid of data as it looks there and then. In that situation users often find an export to spreadsheet compatible file preferable to printing, which would be possible from SL.
Something akin to number two is pretty much your best bet and is what I've seen done for printing in most Silverlight apps so far.
You can have the app send content for printing back to the web server (i.e. a new handler or query string parameters to a printing page) and pop up another page for the user to print web content from, or you could allow the user to download a file and have them print that.
Sliverlight 3 does not support printing.
If you can wait for silverlight 4, they have given it "high priority"
If not use Writeablebitmap: http://www.andybeaulieu.com/Home/tabid/67/EntryID/161/Default.aspx