I have a very strange cypress runner behavior in one of my scripts. After click on a button the runner window starts wrapping until its height value becomes 0. If I am lucky and the next command is fast enough the wrapping stops in a certain point and the test can be working but in a small height window. I tried to use command cy.viewport(width, height) but it didn't solve the problem. The issue can't be reproduced manually. Does anybody encountered this problem and is there any solution?
Related
When I try to do an Xcode build and it fails, I usually get a long list of warning messages in the "Buildtime" screen on the lefthand side of my Xcode window. The actual error message (with the red exclamation mark) is usually way at the bottom, and I have to scroll for a few seconds to get to it. Also, when I do scroll to it, it then loads more warnings below, so I have to do the scrolling process several times.
Does anyone know if there's a way to either jump directly to the error message, or output all the messages to a file or something?
It's irritates, especially if you are working with react-native project where usually more than 3000 warnings and it takes ages to scroll to the bottom where errors usually shown.
How to scroll to the bottom:
Click on the any message in the "Buildtime" list
Press Option + down arrow
I'm currently using the JavaFX ScrollBar control, which in itself works fine - however I'm not satisfied with the "animation" of the thumb when dragging it.
More specifically:
When I drag the thumb quickly, fast acceleration that is - the thumb animation doesn't follow immediately, but kind of "lags" behind - same behavior when I stop dragging the thumb... it takes a split second before the thumb really starts / catches up to it's intended position.
It's not an issue of heavy layout calculation or so, because I'm experiencing the same with just rendering the ScrollBar alone without any content.
Is there some option to make this "acceleration animation" / "lag" go away? - I haven't been able to find any property to set as of yet.
Thanks,
Set the flag "-Djavafx.animation.fullspeed=true" as part of the startup command via the command line. (Note that you can't do this via "System.setProperty(...)" within the application startup...)
I am trying to implement frame independent movement in SFML, but am having trouble getting it to work. When I had this problem earlier with SDL, I found somewhere that Windows pauses the main thread of an application whenever it is moved (by dragging the title-bar). The problem comes because when the window is being dragged, the clock updates but the movement is not drawn until I let go of the window. When I move the window, the window is no longer being drawn to, but the time is still increasing. Thus, when I let go of the window, the units immediately jump to where they would be if the window had not been dragged.
I tried thinking of a solution, and since Windows only pauses the main thread, I considered just running the entire game in a separate thread, and launching it in main() but that does not appear to work as the same result occurs. I also thought about the extremely low FPS's I get as a result, but I would have no way of being able to differentiate between someone dragging the window and if their game is just naturally running slowly... There has to be a way to either prevent windows from pausing the main thread, or doing something that prevents this issue, but I haven't found any sort of solution on the internet...
Here is a link to a zip file which demonstrates the problem. Both Demo0 and Demo1 are the same, except Demo1 uses a second thread to run the program, yet the same effect occurs. Just run both and watch as the delta value is output to command line. Then drag the window and move it to some other part of the screen. When you let go, you should see a very large delta value and the circle should jump ahead depending on how long you had the window suspended. The source code is all there (in the "src" folder), so I hope people can understand the exact problem: http://www.sendspace.com/file/4er8f4
I see two solutions to the problem:
You can try to see if the sf::Events LostFocus or Resized picks up a window drag, and if they do, simply pause the clock on the game. More information can be found here: http://www.sfml-dev.org/tutorials/2.0/window-events.php
However, if that doesn't work, I would simply add an upper-cap on your delta. Meaning, if the game goes above a certain threshold of delta (1/60 or 1/30), you set delta to a lower value. In your situation though, this cap could probably be really big, like 1/15.
if(delta > 1/15.0f)
delta = 1/15.0f;
Chances are you don't expect your game to be playable at 15fps anyways, and if the user drags the window while moving, the worst you'll have to deal with is a 15fps delta on resume.
I have to make some modifications to a VB6.0 project that I haven't touched in years so my memory is getting a little old.
I have a form and then I make the form bigger in the IDE. When I run the program, the size increase does not show up although it looks perfectly fine in the IDE.
What could be causing this?
If I change other stuff on the same form, the changes show up when I run. The only thing this is happening with is the size.
This form is a lot smaller that the main window so there is space to expand into.
Other forms in my project do not have this same behavior.
What else could I check for?
Look for something that sets the height and width in code at runtime. Use the IDE's search specifically to look for ".Height" and ".Width" and ".Move".
I think that an easier solution might be to set the form's height and width in the form_load event, so it initially becomes as big as desired.
I have an app which creates a series of modeless dialog windows which are shown in a 'cascade. The user is supposed to be able to click on any window to bring it to the top and interact with it.
Here's a screenshot, showing this working as intended. The user has clicked on the window 3rd from the bottom, successfully bringing it to the top.
A user reports that when he runs this, and clicks on one of the obscured window then the window does not rise to the top.
Here is a video showing the problem occurring. It shows a normal cascade of notebook windows, behaving as expected. Then a cascade of my application windows appears, but the user cannot bring any selected window to the top. The selected window changes appearance, indicating that it has been selected, but it remains obscured. ( The video concludes by demonstrating a related problem, which we can probably ignore for now )
The user reports that this problem occurs on other PCs he has tried. I cannot reproduce the problem.
I am completely stumped and cannot even guess what might be causing this.
( One theory I had was that the app had frozen and was no longer responding to paint messages. However, the video shows the user dragging the obscured window out of the cascade, and then the window is painted just fine. It seems clear that the app does not get a paint message, or ignores it, when the window is selected )
The app is written using C++ and wxWidgets 2.9.4 and runs under windows 7
This appears to be a wxWidgets 2.9 issue. When built with v2.8.12 libraries, the user reports that it works fine.
Here is the code to create the windows. Note that the parent is NULL. ( This allows the main application window to be minimized without minimizing the cascade windows - a required feature. )
cNewDataPopup::cNewDataPopup( cPatDataset& data )
: wxDialog(NULL,-1,L"New data",wxPoint(200,200),wxSize(570,242),
wxDEFAULT_DIALOG_STYLE|wxSTAY_ON_TOP )
, myData( data )
{
After some experimentation, I found that adding wxDIALOG_NO_PARENT to the wxSTAY_ON_TOP 'fixes' the problem.
( The following explanation is due to VZ. )
Apparently, specifying the window's parent as NULL is not sufficient to convince wxWidgets that you want no parent. It goes ahead and assigns a parent anyway, more or less at random. This is why odd, unexpected and unreproducible behaviour is observed. The algorithm for assigning a parent was changed in v2.9.x, which is why the odd and unexpected behaviour changes when I upgraded wxWidgets. In order to convince wxWidgets that, yes, really, I do not want a parent for a window, I have to specify BOTH a NULL parent and the wxDIALOG_NO_PARENT style.
The use of wxSTAY_ON_TOP is almost certainly the culprit. If you just need the windows to stay on top of the parent window, don't use this style, either use wxFRAME_TOOL_WINDOW or override WM_SIZE handling by overriding MSWWindowProc() in your parent frame.