Related
Hi all,
First a little background into what I'm attempting...
On my PC, I have a self created program which swaps the desktop image to one selected at random from a predetermined directory. There's lots of nifty features, such as image resizing to fit desktop, support for different images on different monitors in a multi monitor setup. etc.
But enough about that, as it's not really windows mobile related. What is related is the fact i'm trying to implement something similar on my Xperia X1.
Obviously I want it so I can have different images for the today screen when it's in landscape and portrait mode - like the built in themes do. I have to admit i'm fairly miffed that this feature isn't supported nativly in a nice easy non-theme related way. it's nigh-on impossible to find an image that looks good in both aspects.
Anyway, I did have something working. A small program which creates a stwater_480_800.bmp and stwater_800_480.bmp by selecting a random image from one of two predetermined directories, and then plonking said images in the windows directory. (Replacing the two bmp images put there by the theme i was using) No resizing of images or anything fancy, just a straight file copy.
This line of code:
SendMessage(HWND_BROADCAST, WM_WININICHANGE, 242, 0)
forces the today screen to update to the lovely new images after the files have been replaced.
All was well until I installed gtrab's excellent pure windows mobile 6.5 update (http://forum.xda-developers.com/showthread.php?t=588882). And although the app still works for the main part, i.e. it picks an image, and changes the background for the today screen, i have encountered a bug.
The image behind the updated start menu doesn't get refreshed - it stays as whatever the image was when the phone was last reset (Think it's specifically a hard reset? i.e. holding power button down the rebooting with sony ericsson logo etc).
Here's the code i'm currently using (Apologies for lack of comments, despite being employed as a vb.net programmer, i'm self taught and not commenting is a bad habit i've never gotten out of.)
Code:
Public Shared Sub SwitchBG()
Randomize()
Dim curdir As New IO.DirectoryInfo(SharedVars.LandscapeDir)
Dim imagefiles As IO.FileInfo() = curdir.GetFiles("*.bmp")
If imagefiles.Length > 0 Then
IO.File.Delete("Windows\stwater_800_480.bmp")
IO.File.Copy(imagefiles(Math.Floor(Rnd() * imagefiles.Length)).FullName, "Windows\stwater_800_480.bmp")
Else
MessageBox.Show("No Landscape Images!", "BGSwitcherPPC", MessageBoxButtons.OK, MessageBoxIcon.Exclamation, MessageBoxDefaultButton.Button1)
End If
curdir = New IO.DirectoryInfo(SharedVars.PortraitDir)
imagefiles = curdir.GetFiles("*.bmp")
If imagefiles.Length > 0 Then
IO.File.Delete("Windows\stwater_480_800.bmp")
IO.File.Copy(imagefiles(Math.Floor(Rnd() * imagefiles.Length)).FullName, "Windows\stwater_480_800.bmp")
Else
MessageBox.Show("No Portrait Images!", "BGSwitcherPPC", MessageBoxButtons.OK, MessageBoxIcon.Exclamation, MessageBoxDefaultButton.Button1)
End If
SendMessage(HWND_BROADCAST, WM_WININICHANGE, 242, 0)
End Sub
I'd love to know what I have to do to force the start menu image to refresh. I've googled for a while with no joys.
Incidentally, I did discover that i can use .jpgs for the background (makes sense really). Not sure if that will have any bearing, but i'll be changing the code to accept both bmp, jpgs, and probably gifs. Can't see that it will affect my specific problem, but thought it would be worth mentioning.
Once i've got this sorted, i'll be ready to tackle the next stage, which is implementing some form of schedule so i can wake up to a new today screen image every day.
Thanks in advance to anyone with any pointers.
Matt.
Sorry, just realised I should have posted this in the windows specific forum.
Still, any help much appreciated!
Okay, I've managed to do this. Via a hacky work-around.
Basically, I realised after a bit of playing, that if you set a "normal" wallpaper, all it does is create a registry key. But, rather handily, the start menu and lock screens (lock was also affected by this bug) would see this change, and update their pic.
Also, rather handily, if you set the registry to an image that doesn't exist, the image then defaults back to the appropriate stwater
so the workaround is as follows...
Every time i run the switch code, I write an incrementing value to the HKCU\software\windows\today\wall registy value. This can be anything, providing it's not a "real image"
when you next open the start menu, it looks for this "new" image, can't find it, so loads the appropriate stwater image.
I'm gona stick the program in an Xperia forum for some feedback/suggestions.
edit: link to app: http://forum.xda-developers.com/showthread.php?t=594763
Hey all,
I've been searching for techniques people use to make transparent controls. The problem with windows mobile is that windows always have the CLIPCHILDREN window style set. So you can't grab the contents of the parent window (in WM_ERASEBKGND for example) because it isn't there.
One technique would be to have the parent pass the handle of the background DC it uses to the child control but that involves having a memory DC around all the time. And if the child control is covering any sibling controls you'd be out of luck as well.
Another solution I've read about is to temporarily hide the child window so the parent window is forced to redraw the parts that would normally be obscured by the control. I personally do not like this approach. (the drawbacks are also discussed on some MS forum, i'm not allowed to post outside links yet, google for "Rounded Buttons : Does any one see any problems with this method" and you will find it)
So, there are ways to achieve what I'm looking for but they are far from optimal. Just wondering what everybody else is doing to achieve this.
The responses in that thread are pretty much spot on (funny to find I know over half the posters in that thread by reputation).
If you want to do this well, you really need to draw your own stuff, making a complete custom UI.
There is no proper way to do this in Windows Mobile (without runtime kernel patching, that is ).
Chainfire said:
The responses in that thread are pretty much spot on (funny to find I know over half the posters in that thread by reputation).
If you want to do this well, you really need to draw your own stuff, making a complete custom UI.
There is no proper way to do this in Windows Mobile (without runtime kernel patching, that is ).
Click to expand...
Click to collapse
What do you mean by "drawing your own stuff"? I am drawing everything myself now in all control i made using AlpheBlend() where needed. But that still doesn't resolve the background issue. Or are you referring to just drawing everything in a single WM_PAINT handler and only having one screen DC?
PegNosePete said:
What do you mean by "drawing your own stuff"? I am drawing everything myself now in all control i made using AlpheBlend() where needed. But that still doesn't resolve the background issue. Or are you referring to just drawing everything in a single WM_PAINT handler and only having one screen DC?
Click to expand...
Click to collapse
Well the method I use in my own new UI's is indeed per form (excluding WinAPI controls like edit boxes and such) draw using only one DC.
The problem is that any 'windowed' control, the parent will not draw to the DC if a 'windowed' control overlaps. Due to CLIPCHILDREN all data drawn to that position is simply lost.
Now, handling WM_PAINT you can get the entire update region, which tells you which parts of your form have to be redrawn. You must use this information, because blitting the entire form is very slow!
In essence, to do this right you well end up faking most of the GDI system, including your own 'fake' child windows, invalidating and revalidating portions, calculating the intersections of your 'fake' invalidated regions of the screen with the update region you get in WM_PAINT and redrawing those parts.
There are several different strategies to go about this, one is to redraw on demand, another one is to use double buffering.
I personally mostly use the double buffering technique, as this easily provides every 'fake' control with a bitmap of it's own region. A child control can then alphablend using the parent's buffer as one of the alphablend sources.
You can of course combine this with keeping state information whether a child, grandchild, etc is using alpha / transparency and this with an algorithm deciding which control needs double buffering or can draw on-demand, which can give both speed and memory use advantages. In a lot of situations you can then suffice with only double buffering the 'top' component (form) and a select number of child components.
Of course two drawbacks of per-control double buffering are speed and memory use. You can eliminate the complete-form double buffer with some smart coding and calculating. This will give you a slight speed and memory advantage. Memory use is high because many of your controls will have a copy of their current state.
This can be as complicated, feature-filled, fast and efficient as you are willing to make it. The better you can design the code the better it will work, but it is not a trivial task. There are many ways to go at this, no one way is definitely better than the other ways. It depends on what your applications does with it's display, how simple you are drawing (are you making a simple white background, or a background based on images for example gradient?), which method is more efficient.
The other method is getting the update region and actually perform redrawing of those invalidated sections (instead of copying from buffer). I can tell you from experience that if you are using image backgrounds and alphablend calls, this will be _much_ slower than double buffering (if done right).
I know all of this probaby makes little sense, I'm not a hero with explaining things ... you really have to figure this out for yourself, I guess.
Other advantages of building your own UI system are that if you do it smartly and buffering, it is very easy to port to directdraw, and possibly even GL. But I must warn you, on far the most devices actually using directdraw for this stuff is not much faster, it is in fact hardly noticable. If you manage to make a GL port, that can especially on older HTC devices (pre-HD2) be much faster.
Ok here we go. I have been looking for a long time to find an app to MIRROR the current screen. This would mainly be for making a HUD(Heads Up Display) while in a GPS program. I have yet to find one, no do i have the skills to make one.
I'm thinking this would be fairly simple, "a capture program" to mirror the current image displayed. Shall we call it Shake2Flip
Is anyone up to the challenge.
Now this program ... would it have to display ONE image flipped, or keep the screen updating while staying flipped?
Cyclonezephyrxz7 said:
Now this program ... would it have to display ONE image flipped, or keep the screen updating while staying flipped?
Click to expand...
Click to collapse
Could be live or Update every few sec.(live if possible)
That ... I don't believe is possible. I could be 100% wrong though. As far as I know, it is not possible to grab the screen of window that is NOT active [on Windows Mobile]. Further, You can't simply hack into a WM_PAINT message to flip everything.
I would even suggest placing a hook on the Display driver, which is not really possible ... I guess in theory one could make a program that monitors the display and virtually flips coordinates [on the x-axis] ... I personally would not have any idea how to do such a thing [since it requires a hook, or a full replacement of the Display DLL]
Then again, i am not that experienced with Windows Mobile ... so I could be entirely wrong...
..::H.O.W...T.O...N.A.T.I.V.E::..
Hello,
today I had decided to start this thread about native development for WP7.
At the current moment I don't upload/attach any working stuffs to this message. It will happen a bit later, after new DFT ROMs release. This is because it's very difficult to run them for now.
Let's start from current achieved results:
1) It's possible to run any EXE files (after "FullUnlock")
2) Those EXE files can do any operations in the system (after "FullUnlock")
3) It's possible to show some GUI from this applications. But GUI has legacy Windows CE style, it's impossible to create Metro-style applications for now.
How can it be used by community?
We can develop a lot of homebrew applications: like porting emulators, old native applications, video players and etc.
It can be possible to port famous TCPMP player for example and get ultimate playback on Windows Phone 7!
Is it possible to run old Windows Mobile 6.5 applications without modifications?
No, it's not possible. A lot of different APIs are missing for those applications.
Is it hard to modify old Windows Mobile 6.5 applications?
Well, it's almost same like porting to pure Windows CE, but a lot of Windows CE stuffs are "damaged" inside Windows Phone. They just doesn't work right, because nobody never used/tested them before
Photos of sample "WP7 Native test"
Information for developers you can find in the next messages.
So I will release demo WP7 native application, when we fix issues with FullUnlock.
Demo will be as binary EXE file. And as VS2008 project, which can be good start point for other developers.
Now this thread dedicated for discussion, share ideas and thoughts.
DFT, Cotulla
Information about "FullUnlock"
Information about "FullUnlock"
DevUnlock actually allows only to deploy XAP files from external sources.
It doesn't give more privileges.
So we (DFT) developed "FullUnlock". FullUnlock is implemented as replacing some system files by wrappers, which allows any kind of access (disable access checking at all)
We replace LVMOD.DLL which used to check files and data (checksums, certificates and etc) and POLICYENGINE.DLL which implements internal objects access checking.
All written before means that FullUnlock at the current moment only possible by flashing custom ROM to device. In future maybe we can find good ways to do it without flashing, but for now I don't see any ideas how to do it without flashing.
Maybe we can replace DLLs inside \Windows\ directory (put a shadow copy), but I am not sure if it will work really. It's stuffs for future experiments.
It can be possible to do something near by editing policy values, but it need big research to find right way. As it still won't disable file checking, maybe we can add own certificate to right store and then sign files with them.
The last DFT 7720 MANGO ROMs contains FullUnlock, but it doesn't work as expected there few issues. as well some users got issues with debugging on those ROMs and etc. We will continue work under it
So I will release demo WP7 native application, when we fix issues with FullUnlock.
Demo will be as binary EXE file. And as VS2008 project, which can be good start point for other developers.
Now this thread dedicated for discussion, share ideas and thoughts.
For developers
For developers
(users do not read! danger for brain!)
First of all I want to talk about abilities of native code.
Most applications built in inside WP7 are native. But they don't use usual Dialog UI style, they are using some kind of Silvelight scripts. This kind of UI is called "UIX".
Main idea of UIX that DLL files have UIX resources inside which describe whole UI.
Something similar is used inside CE 7.0 Slivelight - there some xml compiler which make binary data and put them as resources inside DLL. I don't know how to decode this binary data.
Seems Zune desktop application also using this framework.
So UIX used some kind of scripts for UI part and callbacks for all actions.
If we decode this UIX format, we will able to change/modify UI as we want, like it was before with regular resources inside DLL. But UIX must be much more powerful.
We can't use UIX for native application because we don't know how to use it, how to make proper binary data and etc. It's hard to reverse.
But native application can have some GUI with Windows CE style (you can see examples on the photos above)
Another issue: If you call API function "CreateWindowW" you won't see anything on the screen. It seems because shell handle all output, so window doesn't visible.
After some searching I found inside some test ROM nice DLL called "WindowTreeUpdater.dll". After looking inside and decoding functions parameters, it's working!
Basic idea: you create window and call function from this DLL and Window appear on the screen. There seems some kind of proxy engine to output legacy windows on top of shell output.
Nice, it's working...
So we can use usual windows for UI inside native application.
There present standard controls, but they work rather laggy (hey, and looks too).
Basic controls like PushButton, Static, CheckBox, Radiobutton, Icon are working.
About extended controls: (Progress bar, list view, and etc)
they come from Commctrl.dll usually, it was present inside Initial/NODO releases, ut it was removed inside MANGO. I was able to run NODO Commctrl.dll under MANGO after some modifications. But all this controls are shown on screen, but they don't do anything on input. So you can see toolbar, but can't press any button.
CommDlg.dll is missing and never was inside WP7.
There present AYGSHELL.DLL, but most functions are broken. For example, I was not able to create menu bar.
So, a lot of functions are broken, like MessageBox not working.
But we still can create own custom controls and use them for developing.
For example porting TCPMP means that we will need reimplement UI fully - because toolbar doesn't work. slider also won't. Maybe get and reuse some source from ReactOS or NT40 CommCtrl
reserved1reserved1
reserved2reserved2
reserved3reserved3
This is some crazy ****! I like it
for...all...devices!? If possible...damn
I just came...
Holly smoke !!!!!!!!!!!!!!!
Way to go guys....BRAVO... This is a major breakthrough for wp7 dev
Once again well done DFTeam
You guys are beasts...please keep it up
for...all...devices!? If possible...damn
I just came...
Click to expand...
Click to collapse
For now it's only for HTC devices with flashing custom ROM
The UIX/UIB scripts are a real pain.. I tried going through them a while back to change the annoying notification system (10 seconds? Really, Microsoft?) and figured it would all boil down to the usual XML-style script that WM6.5 and other MS products use, but the format is newer and there doesn't seem to be an easy way to decompile them.
From what I do know, however, is that it's more of an encoding than a compilation, and can be decoded if we can figure out what all the different headers mean... but that's a serious reverse engineering project.
Keep it up.is it possible to add Samsung device into support list?
Great work! Are there any multitasking restrictions for these apps? presumably because they are not Silverlight they will not be present in the task switcher & the app will be in charge of when the process terminates?
Looking forward to doing some nice low-level operations - hopefully this will open a whole new world for WP7 dev
Sent from my 7 Pro T7576 using Board Express
That's great，，，Thanks
Cotulla said:
For now it's only for HTC devices with flashing custom ROM
Click to expand...
Click to collapse
Hopefully this will change when you receive the Samsung Focus and try custom ROMs.
Blade0rz said:
Great work! Are there any multitasking restrictions for these apps? presumably because they are not Silverlight they will not be present in the task switcher & the app will be in charge of when the process terminates?
Looking forward to doing some nice low-level operations - hopefully this will open a whole new world for WP7 dev
Sent from my 7 Pro T7576 using Board Express
Click to expand...
Click to collapse
I would suspect that they won't be killed unless there's an Out of Memory issue (you can see the whitelists for that in the registry), because these processes are not like the silverlight/xna apps that are launched in Taskman.exe. Whether they show up in multitask lists, idk, but they probably won't be killed in the traditional way..
but that's a serious reverse engineering project.
Click to expand...
Click to collapse
yes...
maybe it's precompiled XAML scripts, like inside Managed applications?
Great work! Are there any multitasking restrictions for these apps? presumably because they are not Silverlight they will not be present in the task switcher & the app will be in charge of when the process terminates?
Click to expand...
Click to collapse
I would suspect that they won't be killed unless there's an Out of Memory issue (you can see the whitelists for that in the registry), because these processes are not like the silverlight/xna apps that are launched in Taskman.exe. Whether they show up in multitask lists, idk, but they probably won't be killed in the traditional way..
Click to expand...
Click to collapse
Plain EXE can run without restrictions, but I guess it will be killed at OOM condition still. EXE with window seems all a bit more complex. When I press back button it usually disappear after few seconds. I think window got WM_CLOSE or something at that moment. It should be researched more in the future.
Furthermore, I forgot to say: Interesting thing, before MANGO WP7 supports native XAP files too!
There was few files nativeinstaller* which implements native installation. There references inside for setup.dll and _setup.xml like in old CAB files.
But it was removed from MANGO seems
Cotulla said:
For now it's only for HTC devices with flashing custom ROM
Click to expand...
Click to collapse
Would we be able to install an old application like fpsece for windows mobile? One of the biggest things I miss about windows mobile! I get paid today so I will be making a donation for your hard work! I'm currently using your custom rom on my HD7! Thanks again, and keep up the good work!
支持DFT論壇！支持xda-developers！至於你信不信，反正我是信了！
Oh hay there,
I've been tasked with making an app for windows 8, that has to fulfill the following specifications.
I've been wondering weather i should use the win RT (metro API) or the windows presentation foundation (WPF) API to do it.
requirements:
Needs to be fast (winRT has a slight edge here due to Ahead of Time compilation, but WPF can be compiled ahead of time too)
Needs to be optimized for touch (it's a draw here, WPF can be made touch friendly and supported touch from day one)
Needs to be able to communicate in background with a number of sensors (WPF has the edge here, as it can access low-level OS components, and is also not restricted should it go to the background)
Needs to be easily modified to support new technologies (This one is a bit tougher. Modifying a winRT app takes a while, it needs around 7 days just to process certification, while an update to WPF can be delivered right away. On the other hand, winRT will probably have high level APIs to handle new technologies, whereas WPF will likely be stuck with the lower end of the API, which will make it harder to modify, especially to those not familiar with windows/.net architecture.)
Needs to run on tablet (WinRT has the edge, as it can run on arm-based tablets as well).
Needs to communicate via NFC, get GPS coordinates and take pictures (WPF can do this, but again, it has lower level APIs, which might be hard to adapt in the future)
Needs to be resilient to outside tampering (virus, trojan, malware etc)(WPF is not 100% sandboxed, it has nice runtime security, but the files it creates are not protected, winRT has the edge here)
I need some opinions. I will make my own decision, but I would like to hear some of your opinions first.
Don't ask what the app does, I'm not gonna tell you.
One thing that immediately stands out, GPS. Is this using the tablets integral GPS, a USB unit or a serial/bluetooth unit? If its not integral or USB (and even then, some USB ones are USB>serial adaptors followed by a serial unit) then WinRT wont function with it. You dont get any access to serial ports, parallel ports or the onboard i2c interface via WinRT. Everything is a higher level abstraction wrapping up low level functionality, you get not raw access to it yourself. Most of these tablets out will be using a serial GPS as that is what is most common (or possibly an i2c one but thats something I have never seen before) and WinRT will provide a nice set of wrappers to let you interface with the integral GPS only, but it wont give access to the serial port or the bluetooth serial profile which means it will ignore bluetooth, external serial or certain USB GPS devices. So yes, WPF would certainly have the edge there. But if we are just talking the GPS chip built into the tablet, WinRT will suffice and provides easy access to all onboard sensors, its only external ones that will cause headaches.
WinRT vs regular .NET speed wise likely wont make much difference. I'm not sure that WinRT is fully AoT dependant for its apps (except C/C++), I think it still falls back on .NET, and even if it is AoT the .NET JIT is almost as effective (and with some kludging can be set to AoT I think, mono certainly can and can cope with WPF applications).
I dont own a tablet so cant say too much on touch, I have only handled display model tablets. Tbh, I found most desktop apps annoying on tablets. even if you enlarge buttons and fonts to make them more touch friendly you can run into additional issues, a menu thats too long to fit on screen cant necessarily be scrolled with a touch friendly gesture (well, you can try, but your probably going to have to write some of your own code, might not be that hard actually, I havent tried). If the app is purely meant for touch then I would go WinRT unless there is a specific reason not to.
Updating taking 7 days I dont see as a major problem, everyone else does it and on numerous platforms. It may well take 1 day to integrate a new tech into a WinRT app and 2 weeks on the WPF app in which case the WinRT guys still get the new tech before WPF, or vice versa is equally likely.
NFC communications, GPS and cameras are all easily done in WinRT (with the previous restriction, device only, non external, I assume a webcam works though).
WinRT is probably the more secure option too.
If I were you I would write down each little thing the app needs to do in order to function, ie access a specific type of GPS (you already said you wont share, thats fine). Then go down the list and start ticking off which ones WinRT has the technology to do. We can pretty much assume that eventually WPF will also do it so there is little reason for a WPF checklist. If you get to the bottom of the list and WinRT is fully ticked off, then go with a WinRT app. If there are a few things missing, well then start to weigh up whether it would be better to try and get a WPF app playing nicely with touch and implementing a few things at a lower level or alter the design specification to fit WinRT, I assume there is a client involved here, if there are issues sit down with them and discuss your thoughts and see if they are happy with changes to go one way or the other.
SixSixSevenSeven said:
One thing that immediately stands out, GPS. Is this using the tablets integral GPS, a USB unit or a serial/bluetooth unit? If its not integral or USB (and even then, some USB ones are USB>serial adaptors followed by a serial unit) then WinRT wont function with it. You dont get any access to serial ports, parallel ports or the onboard i2c interface via WinRT. Everything is a higher level abstraction wrapping up low level functionality, you get not raw access to it yourself. Most of these tablets out will be using a serial GPS as that is what is most common (or possibly an i2c one but thats something I have never seen before) and WinRT will provide a nice set of wrappers to let you interface with the integral GPS only, but it wont give access to the serial port or the bluetooth serial profile which means it will ignore bluetooth, external serial or certain USB GPS devices. So yes, WPF would certainly have the edge there. But if we are just talking the GPS chip built into the tablet, WinRT will suffice and provides easy access to all onboard sensors, its only external ones that will cause headaches.
WinRT vs regular .NET speed wise likely wont make much difference. I'm not sure that WinRT is fully AoT dependant for its apps (except C/C++), I think it still falls back on .NET, and even if it is AoT the .NET JIT is almost as effective (and with some kludging can be set to AoT I think, mono certainly can and can cope with WPF applications).
I dont own a tablet so cant say too much on touch, I have only handled display model tablets. Tbh, I found most desktop apps annoying on tablets. even if you enlarge buttons and fonts to make them more touch friendly you can run into additional issues, a menu thats too long to fit on screen cant necessarily be scrolled with a touch friendly gesture (well, you can try, but your probably going to have to write some of your own code, might not be that hard actually, I havent tried). If the app is purely meant for touch then I would go WinRT unless there is a specific reason not to.
Updating taking 7 days I dont see as a major problem, everyone else does it and on numerous platforms. It may well take 1 day to integrate a new tech into a WinRT app and 2 weeks on the WPF app in which case the WinRT guys still get the new tech before WPF, or vice versa is equally likely.
NFC communications, GPS and cameras are all easily done in WinRT (with the previous restriction, device only, non external, I assume a webcam works though).
WinRT is probably the more secure option too.
If I were you I would write down each little thing the app needs to do in order to function, ie access a specific type of GPS (you already said you wont share, thats fine). Then go down the list and start ticking off which ones WinRT has the technology to do. We can pretty much assume that eventually WPF will also do it so there is little reason for a WPF checklist. If you get to the bottom of the list and WinRT is fully ticked off, then go with a WinRT app. If there are a few things missing, well then start to weigh up whether it would be better to try and get a WPF app playing nicely with touch and implementing a few things at a lower level or alter the design specification to fit WinRT, I assume there is a client involved here, if there are issues sit down with them and discuss your thoughts and see if they are happy with changes to go one way or the other.
Click to expand...
Click to collapse
Thanks for the response
The tablet picked for this job has the following minimum requirements:
Intel z2760 atom processor (apparently, they prefer x86 over ARM)
2 GB of RAM
NFC, GPS, Bluetooth (integrated, as in the tablet has no external USB adapted sensors or something)
mini USB
front camera 2 MP
back camera 8 MP
64GB storage
It's basicaly an asus vivo tab smart.
I suppose the GPS and NFC are built in. I haven't developed much with winRT, so i don't know all the ins and outs.
Btw, did Mono get WPF working? Last time I checked they said WPF was too large scale for them to port.
mcosmin222 said:
Thanks for the response
The tablet picked for this job has the following minimum requirements:
Intel z2760 atom processor (apparently, they prefer x86 over ARM)
2 GB of RAM
NFC, GPS, Bluetooth (integrated, as in the tablet has no external USB adapted sensors or something)
mini USB
front camera 2 MP
back camera 8 MP
64GB storage
It's basicaly an asus vivo tab smart.
I suppose the GPS and NFC are built in. I haven't developed much with winRT, so i don't know all the ins and outs.
Btw, did Mono get WPF working? Last time I checked they said WPF was too large scale for them to port.
Click to expand...
Click to collapse
I think mono on windows gets WPF as it can fall back on the live already there, they haven't got a Linux or mac version for sure though, only winforms although there is a 3rd party lib that gives a few controls which look very much like the WPF counterparts which should work on mono. Or there are .net bindings of QT and GTK.
If its the integral GPS as you say, WinRT should cope absolutely fine. Did some more googling and it seems WinRT will only recognise GPS device with an actual device manager entry, that is what discounts serial devices, it may actually be possible to give a serial device a kick up the backside so its listed in device manager alongside the integrated one but in your case its not needed.
SixSixSevenSeven said:
I think mono on windows gets WPF as it can fall back on the live already there, they haven't got a Linux or mac version for sure though, only winforms although there is a 3rd party lib that gives a few controls which look very much like the WPF counterparts which should work on mono. Or there are .net bindings of QT and GTK.
If its the integral GPS as you say, WinRT should cope absolutely fine. Did some more googling and it seems WinRT will only recognise GPS device with an actual device manager entry, that is what discounts serial devices, it may actually be possible to give a serial device a kick up the backside so its listed in device manager alongside the integrated one but in your case its not needed.
Click to expand...
Click to collapse
Well I heard 8.1 gives winRT extended device driver capabilities.
Maybe it will work fine by then...
SixSixSevenSeven said:
I think mono on windows gets WPF as it can fall back on the live already there, they haven't got a Linux or mac version for sure though, only winforms although there is a 3rd party lib that gives a few controls which look very much like the WPF counterparts which should work on mono. Or there are .net bindings of QT and GTK.
If its the integral GPS as you say, WinRT should cope absolutely fine. Did some more googling and it seems WinRT will only recognise GPS device with an actual device manager entry, that is what discounts serial devices, it may actually be possible to give a serial device a kick up the backside so its listed in device manager alongside the integrated one but in your case its not needed.
Click to expand...
Click to collapse
Well, we decided to go for WPF^^
mcosmin222 said:
Well, we decided to go for WPF^^
Click to expand...
Click to collapse
Well, if microsoft gets something right, that is the .net framework.
Kinda funny I can actually call winRT assemblies from WPF(non UI ones ofc).