Ok, this might be a silly question but...
Is it possible to have a custom xaml load/splash screen within the xap?
There is a game site I wish to upload my Silverlight game to, which only allows a single xap to be uploaded, and so I wondered whether there is a possibility of modifying the splash screen that it uses.
My gut feeling is that this is impossible, but I thought I might as well ask.
You can't have a true splash screen that is within the xap file. The whole point is that the splash screen is displayed while the xap file is downloading, so it can't be inside of it.
There's a great MSDN page detailing several different aspects of splash screens, as well as a how-to article that walks you through the basic process.
Who ever is hosting these silverlight games should be responsible for having their "splash screen" for when the xap's are loading.
However, there is nothing from preventing you to create your own splash screen(s) as these are typical within games (and no, the point of a splash screen is not necessarily to hide the downloading/loading of something, especially in a game).
Hope that helps.
Related
I am a new in Hololens 2 and I build some Unity sample on it.
When start application, it would placed a white box like that.
When stop application, the white box still on here and I need to click X to close it.
I have searched about that, it seem like about uwp application lifecycle?
Is there any method to close it with C# when I quit my application.
Thanks in advance for any suggestions.
It is by design and can only be closed manually, every app starts in mixed reality by placing an app tile in the Windows Mixed Reality home and these tiles persist and stay at their placed location. For more information please see:App model
In addition to this, you can add a custom holographic splash screen for the app, please refer to this link:Holographic splash screen
This might be a primitive question but I really like to get more information. I have seen many professional programs have a splash screen and during that a progress bar and some text indicating that program is loading...
I want to know what CAN or SHOULD be loaded during such time? Do they load classes or something? I am noob and do not know what requires loading before a program actually starts.
In summary, yes. They load classes.
If the program's design is modular enough, the outer shell can be small enough to run almost immediately on most devices (think mobile phones here) and display a progress bar while loading behavior (features provided by external modules, assemblies in C#) in the background.
However, that's not always the best approach to program loading. If your user interface can be up and running in less than five seconds on a typical client machine, it may not even be worth a progress bar.
Well it depends on the program. I use a loading screen when my game is randomly generating terrain which can take anywhere between 1 second to 2 minutes.
Is it possible to display an icon in the top left corner of a Windows Form that is a different shape than the standard 16X16 pixel icon?
It appears that Skype has an icon that is much wider than standard:
Is it possible in a Windows Forms app?
You can do this but it's probably more effort than it's worth just to have a larger icon.
Hans has posted an article that roughly points to the information needed to figure out an answer this question, but hasn't posted an answer itself and so I'll clarify.
The old (pre Vista) way to do this is to override the WndProc method on your form and handle the WM_NCPAINT message. Note that this means that you are now responsible for drawing the entire window frame (the window border, title, close / restore icons etc...), not just the icon - i.e. this is a lot of effort to do a relatively minor thing.
The newer (post Vista) way to do this is to use the DWM API - note that this API is not directly exposed through the .Net Framework and so you need to use P/Invoke for this in C#. The bit that you want to do is the section titled "Drawing in the Extended Frame Window", where you extend the area that you are responsible for drawing outside of the normal client area and into the window frame. This is less hassle than it used to be (you don't have to draw things like the close buttons), however still means that you take responsibility for a lot of things that you wouldn't normally, like hit-box testing for resizing and moving.
Basically its nowhere near as simple as providing a larger icon and for most applications its probably way more effort than its worth, however you can do this in C# and that article should get you started if you really want to give it a try.
I know your looking for a plain code way to do this, but I invite you to check out DevExpress manged (yes it's third party forgive me), just google it.. I seen this thread and I started asking questions at devexpress with support and got some impressive results that you might be interested in.
Here is the ticket I put in... http://www.devexpress.com/Support/Center/Issues/ViewIssue.aspx?issueid=Q399941
Here is the result... http://www.devexpress.com/Support/Center/GetSCAttachment.ashx?id=684270b5-faed-415e-9010-64338523f8cf
So Far I used this on Xp, Vista and Windows 7 without problems using winforms only.
I hope this helps or gives you another option if the windows API don't pan out like you want on different versions of windows.
Thanks,
David
Don't think it's an icon, if you mean precisely the ICO image format.
Considering the Skype window is definitely ownerdraw window, that image can potentially be whatever you want format.
The trick is, basically, render an image skipping the pixels of some color (background color) of the "icon", so render it in "transparency".
This article can give you a hint:
Drawing Transparent Images and Shapes using Alpha Blending
It's old, but always a good one.
Yes. Override WndProc and implement WM_NCPAINT.
I created a app in WPF and as app launches it has splash screen. But I was not sure what is the standard size for splash screens or what is the size Office 2010 is using for their splash screens.
The Office 2010 suite splash screen is approximately 500 x 335 for its splash screen.
I'm not sure if there are any "standard" sizes for splash screens, but you could try looking at the Patterns & Practices documents or UX Guidelines documents that Microsoft publishes and see if they are mentioned there.
Interestingly enough, the Windows 7/Vista UX Interaction Guidelines contains the following section:
Reconsider animated splash screens (as
well as static splash screens). Often
splash screens just draw attention to
how long a program takes to load, and
they wear out their welcome quickly.
While splash screens are acceptable if
they are displayed only when user
interaction isn't possible, whenever
practical a better alternative is to
design your program so that users can
interact with it immediately, even
while it is still loading.
There is no standard. I would avoid making it too big and I'd definitely let the user switch it off if they wanted too - they often perceive that it slows down the startup.
I have a C# Windows application (i.e. not a web app) in Visual Studio. The original development environment was a Dell Latitude D800 with a 1920x1200 pixel screen. Since the large number of pixels made the text very small, I adjusted lots of different default fonts in the name of readability.
I have moved development to new laptop, a Latitude D630 with 1440x900 display. The app was moved by creating a new project on the new machine, and adding the existing objects/files/etc.
THE PROBLEM is that many of my forms are no longer displaying uniformly. Some are now too large so that items on the right are out of the frame, and others are smaller with excess space on the right of the frame. It is as if the value of a 'pixel' is now different from one form to another. These changes persist when the executable is installed on production machines.
Any idea on what happened, and how to restore order? Thanks.
A good bet would be to check your font DPI setting. By default its set to 96. Its part of your windows display settings.
As best I understand, that would not explain why some forms are affected differently from others.
Winforms contains a lot of technology designed around the problem of making the display of forms reasonably resolution-independent. But a lot of this technology requires you to understand and use it - anchoring, docking, layout panels, and automatic scaling, for instance. If you've misapplied these properties, you often don't know about it until the day that you first test your app at a different resolution.
Unfortunately, there isn't really a magic bullet answer to the question "why are my forms screwed up?" Your forms are screwed up because resolution-independence wasn't designed into them. There's a whole host of possible problems: you could have controls anchored to the wrong things, someone could have "fixed" a layout problem by overriding automatic scaling on a control, really, it's endless.
Often, the best way to fix this kind of problem in a legacy app is to slowly build up a prototype duplicate of the offending form in a test application and watch its behavior when you resize it and change your screen resolution. That'll help you identify how the form should originally have been designed; you can then take what you've learned back to the original form and fix it.
And then design this into your development process from the beginning. One of the reasons that I don't have these problems in the big UI-intensive desktop app I'm building is that I've made every form in the program resizable, and I resize them during testing all the time to see if they're screwing up. I also test with different screen resolutions as a matter of course. These are the kinds of problems that are really hard to solve once they've become systemic; spotting them early keeps a lot of misery out of my life.
Some experimentation reveals that the declared size of a form apparently affects the size of objects in the scale (length and width units per screen inch) of the form when displayed as a maximized MDI child.
I have no idea why it should affect that.