I use the TTaskbar component in my Delphi application to show the progress of the current operation in the TaskBar.
At the beginning it should show a "Indeterminate" progress (known as pbsMarquee in the context of a ProgressBar).
If I set the status the "indeterminate" animation is only display a single time. I expect it to animate all the time until I change the ProgressState:
tbTaskBar.ProgressState := TTaskBarProgressState.Indeterminate;
Any thing I am missing? What I need to do to dislay the animation all the time?
Related
When I double-click on an animator controller to launch it, the animator tab appears, but when I run the editor, I don't get the usual flow, operations, etc... I only get a static view of the states and transition arrows between them. My parameters do not show the changes they go through either.
I have multiple animations and can switch between them when certain game conditions occur, but nothing really shows when I do so, to see the flow of control, what happens, what goes wrong, the switching, the progress bar, etc...
I have the latest Unity 5.2.0f3 so I wondered if it is just me or others are having a similar problem...
What we need to do is this: Once we hit the play in the editor mode (and have the animator window docked on one side, of course) we just go and click the object in the hierarchy for which we want to analyse the animation flow. And the animator window will start showing the states and the progress bar.
Also, after upgrading to Unity 5.2, it is worth checking the values that were previously set for transition states, for example if vSpeed is greater than 0.1 then start walking. All my set values were messed up; i.e. changed.
I have a paper-button with the on-tap function that opens a paper-dialog that contains a "Accept" paper-button that will close it when clicked.
The problem i'm getting is if depending on my screen resolution, and the dialog's "Accept" button is over the initial button to open the dialog, when clicked, the dialog opens and closes. I'm assuming the on-tap event is being fired to both.
I've tried these 2 methods but they do not seem to help.
event.cancelBubble = true;
event.stopPropagation();
The problem is that a capacitive screens or even mouses can generate multiple tap event on the same spot within a few milisec.
The mouses because a quick change in a high and low voltage (logical 1 and 0) generating an AC signal wich can jump trough on a capacitator (which can be the button two contactor between the air) if the conditions matching. But the onclick event is already catching this case and you does not require to do anything to solve it.
The capacitve screens are capacitators and just rolling your finger should trigger multiple tap events because your skin has different depth of insulation and hard to mark the tap begin and end in some cases.
This physical problem should be solved by the platform, but it is not in every situation currently (but most of the devices are filtering this). Im usally solving this isse with a transparent overlay element wich can catch the pointer events for a little duration so I could catch the "prelling" of a button or the capacitive screen for a few ms.
If a 10-20ms is enough for you then wait a frame in your on-tap function with requestAnimationFrame and then show the dialog. Cheap trick, but it does what it has to, but ultimately you can wait a fix timeout to show the dialog, because you have 100ms to respond a user interaction.
You cannot fix this by manipulating the browser events options though because as I know you dont have option to how much time need to pass until the next same event should happend. But if you wait a frame thats could behave like you add a delay between the events.
I have seen several tools adding a custom button and/or drawing on the title bar of all windows of all applications in Windows. How is that done?
Extra points for an example in Delphi.
EDIT:
I found something for dotNET that does this:
http://www.thecodeking.co.uk/2007/09/adding-caption-buttons-to-non-client.html#.VdmioEDenqQ
How I see this job:
First of all we should be able to paint this button on the our own window caption. This procedure will be used later
This part of the program enumerates the active and visible windows
This part of the program using injection attach our dll to enumerated windows
From injected dll we can draw the button on the window caption
Inside this dll we should process the click on the button
We should have mechanism to send result to our main program
I haven't done this, so the following is what I would investigate if I were to try:
For each application / each top-level window:
Create a floating window and position it over the title bar wherever you want it to sit. Set up the parent / child relationship, but this window is part of your own process. (There are occasionally problems parenting a window from one process to one from another process, but try. I'd avoid injecting into other processes if possible.)
You can investigate the window flags to see if the window has a title bar (ie if you should add a button) via GetWindowLong with GWL_STYLE looking for WS_CAPTION. The same call will also let you see the type of caption / frame, which you can combine with GetSystemMetrics with, eg, SM_CYDLGFRAME to figure out the right size for your button on this specific window's title bar.
This window is now your button: paint, handle clicks etc as appropriate.
Make it a non-focusable window so that clicks to it don't take focus away from the window is is on the title bar of. You don't want clicking it to make the title bar change colour, for example. Do this by setting the WS_EX_NOACTIVATE window flag, something like: SetWindowLong(Handle, GWL_EXSTYLE, GetWindowLong(Handle, GWL_EXSTYLE) orWS_EX_NOACTIVATE).
The main problem is to keep it positioned correctly when the window moves, is resized, etc. To do this, install a hook for the system move events. You can also hook minimize and restore via EVENT_SYSTEM_MINIMIZESTART and EVENT_SYSTEM_MINIMIZEEND. This will allow you to keep track of all windows moving around onscreen, such that you can adjust the button-window position if necessary.
That gives you a window which you can paint as a button (and respond to clicks etc), that visually is "attached" to other windows so it stays in the same place as the user drags the title bar, minimizes or maximises the app, etc, and that is in your own process without cross-process problems.
There are some controls on windows phone that behave different on the first interaction with them than on subsequent ones. e.g. a button control takes about 3-5 seconds to initialize the required action the first time the button is pressed, however on subsequent clicks it works immediately.
Another usercontrol that adjusts its height based on the key press doesn't adjust properly the first time, however the second time it works.
Is there a way to either prepare the controls, i.e. set them in a ready state so that all the clicks behave the same, or can first click can be faked to bypass this annoying behaviour?
Also what is causing this problem?
NB:- I am testing on a Lumia 520 device.
Unfortunately There is no way to prepare the controls. Nokia Lumia 520 comes in Lower Memory Device So Its behaviour seems slow at loading first time in memory and there are so many Background tasks also runnig at a same point of time. You should try it in Higher Memory Device and see the Behaviour.
I found out from this app performance document why it was happening , http://msdn.microsoft.com/en-us/library/windowsphone/develop/ff967560(v=vs.105).aspx#BKMK_Applicationstartup.
I have a loading panel that is set to collapsed by default and only set visible once the button is clicked. According to the document, elements in collapsed state arent added to memory, so this means the first time it needs to initialize the panel and it doesnt need to in subsequent tries.
The other UI control behaving weirdly was also due to its parent's height not being adjusted after its own height is adjusted the first time, so adjusting the parent height as well fixed it.
In my wxWidgets (wxPython) app, I am using a 50 ms timer to do some polling and update a window if there are any changes. If changes are detected it calls wxWindow.Refresh to update the window, and the actual updating of the widgets is done in the EVT_PAINT handler. It would be nice if I could disable the painting and/or the timer if the user is not looking at the window anyway. However EVT_PAINT is still being fired even if the window is iconized or hidden behind a different window.
Is there any way to detect if the window is not currently visible on screen, or to prevent EVT_PAINT events from firing unnecessarily?
There is the IsActive method and the EVT_ACTIVATE event to test whether the window has focus, but I want to keep updating the window if it is unfocussed but still visible. The wxWindow.IsShown family of functions doesn't help, they still return True for hidden/iconized windows.
IsShownOnScreen() could help with the iconized case. Edit: But actually does not.
Or you could trap wxEVT_ICONIZE to detect when the window is minimized.
But to be honest I'm rather surprised that refreshing a window hidden behind another one still results in a repaint. If the window in front is not transparent, this really shouldn't happen.