Well, here is another question that I think has been answered, but I need to ask it anyway. Is it possible to create a customized Silverlight 5 control that can be dragged from one application to another? The behavior I would like to emulate is like the Spy++ Crosshair Icon.
Thanks guys!
So after much research and deliberation, we abandoned the idea of using Silverlight to achieve our goal. The resulting application is a Windows Forms desktop application.
Since no one here decided to help answering this particular question, I will answer it with this: It is not possible to use Silverlight to create a control that you can drag over to an external application and find the Window Handle information for that external app.
Related
I recently started using Xamarin.Forms for a project. Like the documentation mentions, it's great for prototyping. However, I'm really starting to notice limitations of the shared concepts for UI design. In particular, the inability to set custom button content (such as an image) is aggravating. I'm sure there will be several instances where I'll want to change how controls work.
The way I see it, there are two routes I could take. One, continue using Xamarin.Forms and make use of custom renderers. Considering I would still like my UI code to be shared, but also customized from the basic Xamarin.Forms controls, I'm leaning towards this option. Two, use the native Xamarin projects (Xamarin.iOS, Xamarin.Android). This would give me full control over the UI for each platform, but it would also mean more code to maintain.
Like I mentioned, I'm currently favoring the option to use custom renderers with Xamarin.Forms. Could I get some insight from those who have used one or (preferably) both options?
I've mainly used Xamarin.Forms. For the right kinds of apps (ones that are, well, "Forms"-like), it works pretty well.
Writing custom renderers isn't that hard, but the documentation is, unfortunately, not that great. Depending on what you're doing, it can be a bit tricky at times translating between the native control and the Forms layout engine. However once you get the hang of it, it makes sense, and now that the code is open source, you can peek inside to see how the "built-in" controls work.
There are various extensions that add more controls. Some are free and open source, like XLabs.Forms. So the control you need might be out there already.
You can use mechanisms like TapGestureRecognizer to turn an Image or a Label into a button, so just because the built-in Forms Button is really, really lacking in customizability, you can sometimes find other ways to get the same effect and still stay within pure Xamarin.Forms.
Hope that helps!
XamarinForms is good for sample application who don't need to use a lot of specificity of the device.
For complex applications, I advise you to start on Xamarin Ios and Android.
It will take more time to take charge but you will see it is much more permissive
Hello fellow programmers, I come back to you to ask for a quick way to do something with MFC applications.
I have two MFC applications, and I want one to launch the other in a separate thread, so I can have both services running from executing a single exe file.
I'm actually new to MFC so I don't actually know what options I do have. Tried some dirty things but I keep getting duplicated resources problem, not to mention both apps start with BOOL CMainApp::InitInstance() and I'm guessing there is no way to have two initialization instances.
That being said, is there any quick way to rewrite one of the apps to become a secondary dialog without causing too much headache?
Thank you in advance, and excuse me if I'm asking something weird or easy.
It depends on what kind of MFC applications are they? MDI, SDI, Dialog-based?
Here are some options:
If the secondary app is Dialog-based, the conversion is pretty simple: you need to move implementation files for that dialog into the first app and merge the resources.
If both applications are MDI - you can merge their Document Templates so that the first app will be able to operate on all document/view types.
Otherwise - did you consider simply spawning the second app via CreateProcess()? What is the significance of them being run from "a single exe file"?
I am using the Cast Companion Library and most of it is working well however I have not been able to figure out how to show the device chooser programmatically.
Basically when a user chooses a video on my app I would like to show the chooser if they haven't yet connected.
Thanks.
If you are using the MediaRouteButton and it's accessible:
mediaRouteButton.performClick();
you need to "Developing a custom UI with the MediaRouter API’s and MediaRouter.Callback" but I didn't find any example how to do it .
First, I suggest you do not do that. I don't know what you are planning to do in your app so I can't say much but don't do something custom in terms of user interaction/flow that is different from other apps and the apps offered by the framework; people will not expect that.
On the technical side, if you want to open the standard dialog, I am not aware of any trick but I haven't looked at the MediaRouter code in v7 support library for that; since that is open source, you are welcome to look in there and see if there is any simple way to do that. If you want to design your custom one, you should be able to do that; the CastCompanionLibrary provides a sample of the Callback dialog and the one for chooser follows a similar pattern.
As a side note, you mentioned you want to open the chooser when user selects a movie. So how can they select to play locally? Are you planning to add additional selection to that dialog for local playback?
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.
Can existing .net application(in C#) be converted to MonoDroid? or
Can we port an existing .NET web app to Android using MonoDroid?
MonoDroid is intended to allow you to develop applications in C# as opposed to Java; not as a means to drop an existing application into place.
You asked about a web app, but I'm assuming you mean an ASP.NET web app, which wouldn't map to the Android API, and couldn't simply be copied over. Even taking your HTML and dropping it into something like Titanium would still require a lot of JS tweaking to make it work.
I have a feeling you're looking at a re-write. Maybe if you can provide more details (is this an ASP.NET app, etc.), I could give a better answer.
Yes no problem. But it wouldn't be an automatic process, nor a particularly simple one. All the UI elements, persistence stuff and so on (the platform specific parts of your application) will need to be redone. Depending on your app, and how it is written, this may be a major part, or a relatively small one. The more corners that were cut originally, the more it will cost to port over.
In addition to Tom's answer, I would say it has some limitations(link 1 and link 2) . I blogged some other interesting moments here.
Here is a good example of cross-platform mobile application (monoDroid, monoTouch, WP7).