I have some specific text formatting requirements for an assignment, so I am using peek() to try and see the next character and decide what to do, but sometimes my peek() returns \xff. What could this mean?
It even stays at that point too. After doing a couple of get() It can't seem to move past that point
Related
I am facing several situations where an element can't be clicked using cy.get().click() just because the elements have not loaded. However, if i add even the smallest of waits like cy.wait(100); the elements become clickable and my code runs fine.
Can this practice of explicitly calling cy.wait() be avoided?
I think if I can somehow set a fixed wait of cy.wait(100) i.e 0.1ms between all the steps my issue would be addressed but I don't know how to do it.
I've found a solution to this, posting it for others to use later
cy.get('<your-selector-here>').should('be.visible').then( ($el) => { $el.click() } )
you can simply use this assertion .should('be.visible') to replace the explicit wait calls.
However, there's a catch to it; this only works for the cases where you're 100% sure that the element would appear. If the element does not appear, the assertion will simply fail and the test won't continue further.
One Solution is, you can use
Cypress.config(defaultCommandTimeout: 10000) to increase default command time out for the specific situation.
This increased time out will work for all the lines, after the execution of this code.
For a QTextEdit* te I have noticed that sometimes te->document()->size() returns (0,0) and sometimes it returns the actual size. In both cases, te->toPlainText() returns non-empty text.
What can be done for it to return the size?
Is there some refresh method so the document will definitely return the size after it?
Try to call QApplication::processEvents() before checking size. It will cause processing of all pending Qt events, so after this call all sizes will be updated. Note that invisible documents still may not return correct size.
Calculating layout of text is heavy operation, especially when text is long, so this have to be delayed as possible. I'm pretty sure that you get this zero size somewhere in construction time.
How you can overcome this problem?
Best approach is lazy initialization. Do not perform calculation until some value is relay needed (it you do this properly you will never get zero size).
Other approach is to enforce calculation of document layout. You can do it by calling setTextWidth(), setPageSize() or idealWidth() depending on context of your task.
idealWidth() is perfect if you do not wrap lines and don't have page size.
When the player character goes into the Staffroom at the orphanage/boarding school they live at, said player has two turns before they hear the manager's footsteps coming down the hall and they are urged to hide. I've done this through use of number variables. At this point I have another number variable (set up like a true/false thingy by only using 0 and 1) to govern whether or not trying to do anything except 'hiding' or 'hiding wrongly' gives the response 'There's no time for that, just hide!'. The problem is this: Whenever I start the game, ANY ACTION is rejected and met by 'There's no time for that, just hide!'.
Code:
NOTSITS is a number variable.
When play begins:
now NOTSITS is 0.
Every turn when the location is the Staffroom:
increase NOTSITS by 1.
Every turn when the location is the Staffroom:
if NOTSITS is 2:
now HYF is 1;
say "From the hall outside, you hear footsteps... Shit, that sounds like Rodger![paragraph break]HIDE!".
HYF is a number variable.
When play begins:
now HYF is 0.
Every turn :
if HYF is 1:
instead of doing anything other than hiding or hiding wrongly:
say "There's no time for that, just hide!".
Hiding is an action applying to nothing.
Understand "hide" as hiding.
Hiding wrongly is an action applying to one thing.
Understand "hide in [something]" as hiding wrongly.
Instead of hiding:
try entering the empty cupboard;
now HYF is 0.
Instead of hiding wrongly, say "Don't waste time with stupidity, just hide!"
Please don't suggest using Inform 7's own time system to solve this. I tried that and it was a far bigger shizztorm of problems than this has been.
I think the problem is that you're relying too much on every turn rules, but they run after the actions have all been processed, so it's too late for them to do what you want them too. I also defined hiding as a synonym for entering, because that action already exists, and it's what you want to happen. So try this instead:
First turn is a truth state variable. First turn is true.
The staffroom is a room.
In the staffroom is an enterable container called the empty cupboard.
Understand "hide" as entering.
Carry out entering when first turn is true:
now first turn is false;
Understand "hide in [something]" as a mistake ("Don't waste time with stupidity, just hide!").
Instead of doing something other than looking or entering when first turn is true:
say "There's no time for that, just hide!";
(Also in the future it will help if you provide the full source code, or at least all that's relevant. This time you left out the staffroom and cupboard.)
You can specify an action and its time of appearance after entering a room:
After going to Staffroom for the first time:
manager comes in three turns from now.
At the time when manager comes:
YOUR STUFF
When I am using the terminal, I will often press, for example, alt plus an arrow key, and instead of doing what I expect (usually moving the cursor) I get a "Control Character" like [[A; or something like that. What letters I get seems to be very context sensitive, its different if there is a program running in the foreground vs. actually at a prompt, its different during the boot sequence, and it seems to be different depending on which UNIX I'm using. I know what a few of them are for (^C, ^D, ^Z) but I have no idea what the rest are used for or where they came from, or why they haven't been gotten rid of yet.
We have a flex app that will typically run for long periods of time (could be days or weeks). When I came in this morning I noticed that the app had stopped running and a white exclamation point in a gray circle was in the center of the app. I found a post about it on the Adobe forums, but no one seems to know exactly what the symbol means so I thought I'd reach out to the SO community.
Adobe forum post: http://forums.adobe.com/message/3087523
Screen shot of the symbol:
Any ideas?
Here's an answer in the post you linked to from an Adobe employee:
The error you are seeing is the new
out of memory notification. It is
basically shielding the user when
memory usage gets near the system
resource cap. The best course of
action here (if you own the content)
is to check your application for high
memory usage and correct the errors.
If you don't own the content, it would
probably be best to contact the owners
and make them aware of the issue you
are seeing.
He also says this in a later response:
Developers can use the
System.totalMemory property in AS3 to
monitor the memory usage that the
Flash Player is taking up. This iwll
allow you to see how much memory is
used, where leaks are and allow you to
optimize your content based on this
property.
I work for a digital signage company and we have also came across this error, however, it is not only memory leak related because it can be caused by utilizing the vector code on that page provided. We have also noted that it occurs without any kind of memory spike whatsoever, and sometimes appears randomly. However we noticed that when we replicated the bug with the vector error, it was saying it was an out of memory error - which clearly was not the case.
In our internal tests we noted that this bug only occurs with flash player 10.1 and up, flash player 10 does not seem to have this issue. Further, there seems to be a weak connection between the error occurring and the use of video. I know this might not be too much help, but just thought you should know it is not only a memory leak related issue. I have submitted this bug to Adobe, and hopefully they resolve it soon.
This can occur when using a Vector.int which is initialized using an array of a single, negative int. Because of the way you initialize the vector class with code such as:
Vector.int([-2])
The -2 gets passed to the vector class as it's initial length like Array(5) would be. This causes an error somehow (and is not checked and raised as an exception).
I have also noted the issue repeating when passing negative values to length of a Vector.
A possible explanation would be that the vector tries to allocate the length its been given immediately.
Since the negative value is being forced into a uint, the negative value autumatically translates to a very large positive value. this causes the Vector to attempt allocation of too much memory (about 4GB) and hence the immediate crash.
if you pass a negative value to the length of an Array nothing happens, because apparently it does not attempt to allocate the length. but you can inspect the value and see that it is a very large positive number.
This explanattion is pure conjecture, I did not hear it anywhere. but it is consistent with as semantics and the meaning of the exclamation mark.
This said, I have search our entire code base for the use of the setter "length" and could not find it used with a Vector. Still, we are experiencing very often crashes of this sort - some of them are caused by actual high memory consumption (probably leaks) but other times it just happens when the memory is relatively low.
I cannot explain it. perhaps there are other operations that can potentially lead to allocation of large amounts of memory other the the setter "lenght"?