I have been searching for an API to capture screen images in a WinUI 3 app (without the user selecting from a picker, as from GraphicsCaptureItem). My goal is to capture screen images under programmatic control and display them on a Canvas element. Most of what I've found so far are APIs that work only on Windows forms.
I can think of some possible ways to do this by using interop to Win32 functionality, but hopefully there is a WinUI 3 compatible library that can be used directly (such as System.Windows.Forms.Screen, which is used on Windows forms).
Thanks in advance for any advice that can be offered.
2/6 - checked out the link from Simon Mourier and tried out a ScreenCapture app that uses CreateForMonitor: https://github.com/microsoft/Windows.UI.Composition-Win32-Samples/tree/master/dotnet/WPF/ScreenCapture. At this point, there would be quite some work to port this app to WinUI 3 as it is quite complex and uses interop for Direct3D functionality. However, it is progress and I appreciate the response.
Winui3 applications have access to the IGraphicsCaptureItemInterop interface. Here is a sample, I suggest you could refer to: https://github.com/robmikh/Win32CaptureSample
Related
I am new to Xamarin and not sure if chose Xamarin.Forms to create a application for ios and android platform has a problem or not.
The application has some features below:
The application will be able to running some code in background without launching application by user.
The application can be launched by a href link or a notification.
The application is able to launch a builtin Camera application, and receive picture data from Camera application.
Thanks,
Bo
The features you are mentioning can be done with both. Actually, anything you can do on Xamarin.iOS and Xamarin.Android can be done with Forms. Because Forms is only an abstraction layer for the UI which is installed by a NuGet package.
Now, having that said when to use Forms or when to use iOS/Android? It is mostly about UI. Are you going to do some advanced or platform specific stuff is is easier to implement that with the platform specific project.
If you UI will be the same in both platforms and mostly consists of some lists and input fields, then that is a very good candidate for a Forms project.
Notice how I said it is easier to do in the platform specific projects. Again here, you can do anything in Forms as well by the means of Custom Renderers, it is just a bit harder to do.
Ideally try it out yourself and see what suits you best.
In regard with your need to execute code in the background. This will be tricky and is very dependent on the platform that you're on. You will definitely have to write platform specific code for that for which you can use the DependencyService to abstract it to your shared code.
However like AlancLui mentioned executing code in the background isn't something that is easy to do on mobile. On iOS it is restricted to accessing location data or playing music, but still your app needs to be running (in the background). Android has something called Services for this, which makes it a bit easier.
The team I'm on created a cross-platform application that runs on iOS, Android, and Windows Mobile that was created using Xamarin's tools and MonoCross. We're looking at MvvmCross as a possible MonoCross replacement but don't want to write the application from scratch.
Does anyone have experience with or thoughts on migrating a Xamarin/MonoCross cross-platform application to Xamarin/MvvmCross? Is it possible for the two frameworks to coexist in the same app (the ideal solution would have us migrate the app one screen at a time).
Thanks in advance.
Following Stuart's advice below I confirmed that it is possible to integrate MvvmCross into an existing MonoCross application.
In the original code a selection on View 1 initiates a call to Controller 2 using MonoCross URI navigation. Controller 2 displays View 2, passing it the data from Model 2.
Following the example in this video I created an MvvmCross View and ViewModel. A selection on View 1 still navigates to Controller 2 but Controller 2 now displays the new MvvmCross View 2. View 2 is data bound to ViewModel 2 which takes over Controller 2's functions of getting the Model data.
I don't know of anyone who's done this recently, but I originally ported several of the MonoCross samples over when I first created MvvmCross. The overall idea of one page to one "ViewModel" stays the same, although the mvvm binding offers more continuous view-viewmodel interactions than the more discrete Controller-Action model.
At a practical level:
MvvmCross itself is very modular and can be used in "CrossLight" mode where it simply provides data-binding and plugins - see CrossLight in http://mvvmcross.wordpress.com/. You might be able to use this for migrating pages one-by-one
MonoCross isn't really very interface/IoC based - so you may find that your resulting MvvmCross migration would also not be interface based either
MonoCross apps tend to use file-linking and #defines rather than PCLs - so you may find it easier to not use PCLs in MvvmCross
I suspect the best option for this migration is to let your team experiment - they already have lots of knowledge about your app and about what they do and don't need and what benefits they do and don't get from a framework.
I am new to both window hooks and Windows 8 metro apps..
I would like to develop a background service/process that:
Checks the "properties" of the metro app that a user just tapped to start (e.g. app that plays music, text document creator app, ...)
Based on the properties found, activate other applications (i.e., before starting the text creator application that the user just tapped, make him select the font face from a popup list)
I am planning on using window hooks to do 1 and 2..
Is this possible?
Thanks!
It is not possible to hook Windows or intercept the launching of a Metro style app from within a Metro style app itself. While it may be possible to do so with a service installed on the machine in a classic way, doing so would be totally undocumented and unsupported. You would have to reverse-engineer the app launching process to have any chance at making it work.
Check this out..
http://social.msdn.microsoft.com/Forums/en/wcf/thread/43df6c8f-f1e3-4aba-af0a-7c4e1db477b6
You can only write client applications using Metro, not server applications.
In your scenario, if you want inter-app communication, recommended way is to use 'Contracts' which are explicitly started by the user.
I'm taking a blind guess here using your 1 and 2 points. Do you intend to handle a specific file type ? say .txt or .wmv ?
If this is your intention, please check here http://tozon.info/blog/post/2011/10/11/Windows-8-Metro-declarations-File-Type-Associations.aspx
There's also a good set of MSDN documentation about this.
You may use API hooking. Check this thread:
http://forum.nektra.com/forum/viewtopic.php?f=9&t=6228
I have an application that will need to better support tablets in the future. I have seen some apps already created with UP1 and ExtLib Mobile Controls but I was wondering if anyone knows of specific functionality that simply is too challenging to even consider bringing to a mobile device?
For example, are there partial refresh issues on specific devices? Can managed beans still be used behind the scenes? Is dynamic content totally viable on mobile?
I'd be interested in hearing what big challenges/functions people had to give up when they mobilized their existing XPage apps.
There isn't really anything in XPages that would prevent building mobile web apps as with other web app dev models. In other words: Everything you can do with web apps on mobile you should be able to do with XPages.
XPages 8.5.3 UP1 comes with Dojo Mobile 1.6.1. However that does not prevent developers from using other frameworks like JQuery or anything else.
There are some advantages in general for native apps and hybrid apps. But personally I think most of the typically rather simple business apps can be built with mobile web apps. If you need local data/offline that might be different though.
You can use Xpages to do anything that is possible with mobile web developement. Dynamic content may not be the way to go for everything, but it will run just fine. In ITANA available for free on openntf.org, i created a simple replication engine to replicate notes tasks from the local device using sqlite to the domino server. This makes it run very fast and allows the app to run offline as well.
So i believe anything you want to try will work, you can make the Xpage output anything you want, from html, to xml, or json, to accomplish your tasks.
I know that XPages was totally incompatible with older Blackberry's. I assume that's not the case these days but back at OS 5.0 I think even buttons wouldn't work. So if you're doing anything with BB make sure it's modern and tested.
We're not really getting tablet support in ext. library until the next dojo rev I think. But there is a preview of tablet support somewhere that you can get. I've not looked yet but it was mentioned at Lotusphere. so if you want to hit tablets you might want to roll your own right now until that comes available.
Tablets are a little more challenging as the mobile controls are designed for the mobile phone size devices. That said with a little trial and error you can get a nice navigator split screen and still use the one page app mobile controls to streamline it, with records opening in their own page just like the phone version. Type ahead as I'm discovering should be handled differently if you are using the iPhone themes from oneui2.1
The oneui2.1 gives your navs and views nice styling. The forms may need a bit of custom styling.
Split your design into custom controls then you can use a server ate xpage for mobile devices and straight web. Or if you forgo the use of mobile single page controls you can always just have a seperate style sheet to accommodate the iPad. Really depends on the functionality needed. Good luck
My suggestion for anyone wanting to do tablet specific development using XPages is to move to Notes 9.0 and dojo 1.8 asap. Dojo 1.8 has an experimental control called ScreenSizeAware. This is miles ahead of anything else either the Extension Library Mobile controls or Dojo provides for Tablet development.
I have experience with Android's search functionality as described here: http://developer.android.com/guide/topics/search/index.html, but haven't been able to find anything similar for windows phone 7.
Alternatively, what is the best approach to provide search functionality within your windows phone application?
The search scope is within the application itself, and while it is obviously possible to implement it myself, I'm looking for something that follows the ui guidelines of windows phone 7, and possibly also an interface to provide search results from the app, even when the search button is pressed while the app is in the background.
You are fully responsible for handling search within your app. There are no WP7 specific guidelines or tools available. Do what's best within the context of your app.
You cannot integrate with the built in search facility to include app specific results with anything returned as part of a bing search.
To add, interface to Windows Phone 7 hardware search button is not exposed to third party developers. You need to provide your own search button in the application and handle it appropriately.