First time I have this problem
This is the last line executed in the init()
and then display() is called
Never faced this problem before. It quits init() at the same point even debugging step by step..
Ps: using com.jogamp.opengl.util.Animator as animator
There is an exception in the init() I wasnt catching before
Related
I am trying to execute a SequentialTransition, but between the animations, I need to execute some commands.
My problem is that it is always executing the last commands passed on the node. Is there any way to fix this?
Where is "is ignored" is the code that I need to be executed in the first animation, then where this "is executed" is the code that I need to be executed in the second animation.
Thanks
private void startAnimation(){
vb_adv.setPrefWidth(197);
ap_services.toBack();// Is ignored
vb_adv.toFront();// Is ignored
ScaleTransition expandAdvertising = new ScaleTransition(Duration.millis(2000), vb_adv);
expandAdvertising.setToX(2);
expandAdvertising.setCycleCount(2);
expandAdvertising.setAutoReverse(true);
ap_services.setPrefWidth(124);
ap_services.toFront();//is executed
ScaleTransition expandService = new ScaleTransition(Duration.millis(2000), ap_services);
expandService.setDelay(Duration.seconds(3));
expandService.setToX(3.7);
expandService.setCycleCount(2);
expandService.setAutoReverse(true);
SequentialTransition sequence = new SequentialTransition(expandAdvertising, expandService);
sequence.play();
}
In the code as you currently have it, you move ap_services to the back of the z-order, and vb_adv to the front:
ap_services.toBack();
vb_adv.toFront();
Then you create and set up you ScaleTransition. Note that doing this part takes essentially no time; all you are doing is configuring the animation which will run later.
The next thing you do is to move ap_services to the front:
ap_services.toFront();
Note that this will happen essentially immediately after the previous calls to toFront() and toBack(), and of course this negates the effect of those calls. So your initial calls are actually executed (not "ignored"), but you immediately do something which undoes their effect.
What you really want is to execute ap_services.toFront() after the ScaleTransition finishes. You can do this by putting that call in an onFinished() handler:
// ap_services.toFront();
expandAdvertising.setOnFinished(e -> ap_services.toFront());
The question is not how to get it working, it works. I am just interested but can't find out what goes on in the background to make it work.
Prime example is the standard Blazor server webapp template, which has a "counter" and a "fetchdata" component.
In the fetchdata component, there is protected override async Task OnInitializedAsync() that gets called, and the component renders itself. If the OnInitializedAsync() does not return in time, the render still happens, in the example just writing out loading... Then when the OnInitializedAsync() actually finishes, the component is magically re-rendered, but what caused the re-render? how is it wired together?
Does the framework peek at the class' memory every so often to figure out if a rerender is needed? Is it just that there is a call for the page render before the OnInitializedAsync() call and one after awaiting it?
This is all based on async programming...
protected override async Task OnInitializedAsync()
{
forecasts = await ForecastService.GetForecastAsync(DateTime.Now);
}
The OnInitializedAsync method you've mentioned has two parts: synchronous and asynchronous. When the OnInitializedAsync method starts executing, a call to the awaitable GetForecastAsync method is made, control is yielded to the calling code, Blazor runtime, that starts rendering the UI without delay. This is the first time your component is rendered. This is also why you must check in code that the forecasts variable is not null. When GetForecastAsync returns and the forecasts variable is populated, more code (if exists) is executed to the end of the method, after which your component re-renders again, this time forecasts is not null, and thus the table is rendered. Of course, this was a simplistic explanation. You can inspect the process, step by step, by viewing the code that does this: It all starts here. It shouldn't be difficult to follow. No magic
Hope this helps...
I try much method i have find to do this, but no one work for me.
I have tried with qApp.processEvents() and with update() but no one work.
void GUI::startLoading(int currentFile) {
ui->progressBar->setValue(currentFile);
ui->progressBar->update();
}
currentFile is an int of the current loaded file from another function.
Here's a screenshot of de dubug that told the current value of the progress bar, but the progress bar don't increment.
Are you doing busy work in the GUI thread? Qt needs to get a chance to process events for the redraw to happen.
update() only enqueues the redraw. Note that setValue() calls update() itself. To avoid this problem, you can call QEventLoop::processEvents() from time to time (e.g. at the same place where you update the progress bar), or use a worker thread.
I'm just looking into CefSharp and am confused about NewScreenshot. I've found lots of references to it as well as example code, but none of it works. I found it marked as obsolete in the 63.0 docs...
Has NewScreenshot been removed? If so, what replaces it (how can I tell that the screen has rendered)? For my purposes a blocking (non-async) method would work fine.
Update:
Searching the source for the latest version of CefSharp I find no reference to NewScreenshot.
I started with the Minimal Example that #amaitland referred to. I made a few changes, adapting it for my use. As part of that change I moved the Shutdown() call to the program's destructor.
When I ran the project I received a mystifying error about calling Shutdown() from a thread different than the thread from which Initialize() was called.
Looking through the code I saw ScreenshotAsync and, as I wasn't (knowingly) using another thread, suspected it may be involved. I looked for another way to get my SVG image and found NewScreenshot. Which of course didn't solve my problem, which was that the GC was running my destructor in a different thread (I had no idea that could happen).
At any rate, by this time I'd shucked ScreenshotAsync for NewScreenshot which is how I ended up here.
I set a breakpoint in my handler (which I haven't included as it's never called). Here's what I hope is the relevant code. I've omitted the init code but I believe it's unchanged from the example.
public static void Main()
{
private const string url = "https://www.google.com/";
browser = new ChromiumWebBrowser();
browser.Paint += OnBrowserPaint;
browser.Load(url)
Console.ReadKey();
}
In stepping through the code in the debugger, I set a breakpoint on browser.Load(url). If I examine browser.Paint, I find errors:
Here's the tooltip for DeclaringMethod:
I have no idea if this is related to my event handler not firing, but want to point it out in the event it is involved.
I appreciate your other suggestions but feel I need to find out why an event that should be firing is not.
I'll be happy to reduce and upload the project if it will help. Oh, and thanks for your help!
I have some async services that I would like to call in different places in Xamarin application. I port my code from native UWP app with Prism.
Some time ago I was able to do this by declaring making methods like
protected override void OnInitialized()
or
public override async void OnNavigatedTo(NavigationParameters parameters)
used await there. However, it stopped working.
Trying to use GetAwaiter().GetResult() blocks execution and results in deadlock.
This is kind of weird, considering that INavigationService.NavigateAsync itself is async method, but samples suggest to use in OnInitialized without any await, which I believe is wrong.
So, does anyone have a suggestion how to proper make async calls in Prism.Forms?
OnNavigatedTo gets called from the UI thread (it is part of the UI Lifecycle). If you block inside that method, you will of course have a deadlock.
Just because NavigateAsync returns a Task and has an async name, doesn't mean everything in that method happens on another thread. It just means it usually does something, that you could wait for.
The problem here is, that OnNavigatedTo is returning void, so it will return to the caller, once you have an await in there. That doesn't stop you from using it, you just cant block there.
public override async void OnNavigatedTo(NavigationParameters parameters)
{
// do sync stuff
await DoSomethingAsync();
// this happens after all the other lifecycle methods
}
Just be aware, that everything after the await just happens after the whole navigation is done. And that exceptions thrown in there will not show up (it's basically fire and forget).
You can always make the continuation explicit by not using async/await and using .ContinueWith(...) instead.