Ok so I am currently creating an program which is based on vcl. User will be adding removing resize move labels images memos etc. in vcl how can user move resize increase decrease heights width smoothly in components at end-user designing?
Should I use external package's or I can do that in-built ?
Related
Using C++/CLI on Visual Studio I want to create a 2D simulation, with the options to change the user's inputs on one side of the screen and the simulation on the other side. (The user's inputs would be used to calculate what to draw for the simulation)
I would like to be able to do this within a panel/fixed region keeping the drawing separate from UI elements (buttons etc). Essentially I would like to draw multiple dots on the screen and the position of those dots changes every second. Trouble is all the examples of of drawing I've seen take up the whole form.
What libraries and how can I use to create multiple 2D drawings either by controlling the colours of pixels or any other way inside a fixed region like a panel?
This really depends on what GUI toolkit you're using.
If you're using WinForms, create a control and override the OnPaint method.
If you're using WPF, I'd use WritableBitmap.
There are other methods for both toolkits, of course, but those are the ones I would use. Plus there's things like DirectX and OpenGL, but it sounds like you want something simple, so those would probably be overkill.
When we build Universal app for Windows 10, in order to support multiple resolutions we can use Adaptive triggers.
In this case for each visual state, separate layout is used. If we have 3 sizes to adopt, for each layout must be created, and as a result for most controls there will be multiple duplicates, which are hidden and becoming visible for appropriate visual state.
All these controls will be loaded to memory and waste RAM, which can be dangerous for low memory mobile phones (like lumia 620).
Is it right solution to use separate view for this case?
Update
If someone needs, here are good and very simple articles about element layout reordering form wintellect (AdaptiveTrigger, changing element positions in grid) and galasoft (AdaptiveTrigger, RelativePanel).
Windows 10 Xaml introduces an attribute x:DeferLoadingStrategy to mark controls to be loaded only when needed. This will let you include all of the controls in the Xaml without loading them into memory unless and until they are actually used. In the mobile case where the device is likely to have only one size actually used (or two for portrait / landscape) the layouts for the other sizes will never load.
For the case where you are using the same controls but just have slightly different positioning I would look at moving them (possibly with RelativePanel), as Jon Stødle suggests in the comments.
If there are bigger changes then I'd look into separate layouts (like you're doing) within the same file or with separate Xaml, but for simple positional changes that's probably overkill.
Question : What are the uses of changing display resolution in full screen mode in GAMES and should it be allowed?
More info : The way i see it,
Privilege perspective : When you request your window manager for a window context, you also have the option via a flag usually to set the window to a fullscreen mode, In fullscreen mode, you can set the window resolution to a resolution of your choice usually from a given list, In most cases, that will change the display resolution, affecting your desktop environment, Should a program that is not your window manager have control over your display monitor?
Bugs : OS / Software depended in mind, When a program faults and trigger a crash, if the program fails to exit correctly, You may still end up with the same resolution asked by your software (also applies to gamma ramps when not using shaders).
Practices : Since the dawn of pc video games as far as i know, You always ended up having a "Native resolution" and everything just getting re-scaled to it, In today's world, You also have "Dynamic resolution scaling" methods and other tricks with frame buffer objects, Do we gain any benefit from actually changing the display resolution?
Performance wise, You can always change other settings to improve performance, Not just resolution.
Aspect ratio in mind, If your display monitor by default is using 16:9 for your desktop environment, Would you actually change it to something else? Obviously you should have the option, but should it be changed through a software that is not your window manager?
Thanks in advance, I may end up revising the question during the first few hours after posting.
Always pick nice defaults that don't change the display mode on launch. If the user wants to go to the graphics settings page and set it to 1024x768 full-screen mode though, let them - they probably know what they're doing.
As for performance, there can be reasons to use non-native full-screen. In addition to the performance benefit you get from drawing fewer pixels, you get access to fixed-function hardware that scales up the image on scan-out. If you scale up in the renderer itself, this is at least one extra full-screen read + write. If you're fill-rate bound, this can impact your framerate.
Something to consider though is that if you have any kind of post-process pass, you will usually be doing a read+write anyway, so you can do scaling at the same time effectively for free. Also, using native resolution for your final target is the only way to get crisp edges for things like text. Often, a game will use a scaled down target for 3D rendering, and merge with a native-resolution overlay.
In a nutshell:
Pick good defaults (windowed, or windowed-fullscreen native resolution).
Allow the user to set the window target resolution and mode (windowed, windowed-fullscreen, or fullscreen).
Allow the user to independently select the 3D resolution scale factor (25% - 200%).
Always draw the HUD and any text at the window target resolution.
I am new to surface programming and stumbled upon this Image which I understand is a slider control on a tag visualization (in this case a card). This slider is
curved as opposed to conventional straight track
has a bigger thumb which displays the current position (thus eliminating the need of a separate label)
has a glowing feel (I understand this is due to overlapping controls with different blur radius)
Can anyone help with how to make such control.
-V
This is a custom-built control rather than a standard SurfaceSlider. It's not build using TagVisualizer either but that's only because the app that this picture shows was built ~2 years prior to TagVisualizer existing.
Now you should certainly use TagVisualizer to streamline an implementation of this but you'll still have to create a custom slider control - SurfaceSlider will not be a good fit because it assumes that the user is moving their finger linearly.
Within your custom arching slider control, you can use SurfaceThumb (which SurfaceSlider itself uses) to get the big glowing thumb... then just needs to listen to the Delta events on the thumb and move it along the constrained path as appropriate.
I have a large data set (some 3500 objects) that returns from a remote server via HTTP. Currently the data is being presented in an NSCollectionView. One aspect of the data is a path pack to the server for a small image that represents the data (think thumbnail for simplicity).
Bindings works fantastically for the data that is already returned, and binding the image via a valueurl binding is easy to do. However, the user interface is very sluggish when scrolling through the data set - which makes me think that the NSCollectionView is retrieving all the image data instead of just the image data used to display the currently viewable images.
I was under the impression that Cocoa controls were smart enough to only retrieve data for the information that is actually being output to the user interface through lazy loading. This certainly seems to be the case with NSTableView - but I could be misguided on this thought.
Should valueurl binding act lazily and, moreover, should it act lazily in an NSCollectionView?
I could create a caching mechanism (in fact I already have such a thing in place for another application - see my post here if you are interested Populating NSImage with data from an asynchronous NSURLConnection) but I really don't want to go this route if I don't have to for this specific implementation as the user could potentially change data sets often and may only want small sub-sets of the data.
Any suggested approaches?
Thanks!
Update
After some more testing it seems that the problem arises because a scroll action through the data set causes each image to be requested from the server. Once all the images have been passed over in the data set the response is very fast.
So question... is there any way of turning off the valueurl fetch while scrolling and turning it back on when scrolling has finished?
My solution is to use a custom caching mechanism like the one I already use for another application. The problem manifests itself because as you scroll past images that have not yet been downloaded, the control triggers itself to go and fetch the as yet non-downloaded files.
Once downloaded the images are available locally and therefore scrolling speed normalizes. The solution is to check to see if the image is available locally and present an alternate app-bundle graphic while the image is being downloaded in the background. Once the image has been downloaded, update the model with the image replacing the stub image that came from the bundle.
This leaves the UI in a very responsive state throughout, leaves the user with the ability to interact and allows for a custom background management of the images.
Of course it would have been nice if Cocoa id all this for me, but then what would I be left to do? :-)