consider the code
for(i = 0; i < 5; i++)
{
if(control.Exists)
{
mouse.Click(button);
}
}
In this, control is a popup window. for the first time of execution, control.Exists = true and for the second time it is false though the control is present. Why is that so? How to make it to be true?
Thanks in advance.
Programs often draw another copy of a control, it looks identical to the eye but it is different. Hence the second time around the loop control refers to the old version of the control but it is no longer present.
Your code is likely to be equivalent to
for(i = 0; i < 5; i++)
{
if(top.middle.control.Exists)
{
mouse.Click(top.middle.button);
}
}
There may be more levels in the UI Control hierarchy but three is enough for the explaination here.
The normal fix is to find the new copy of the control before using it. So change the code to be
for(i = 0; i < 5; i++)
{
top.middle.Find();
if(top.middle.control.Exists)
{
mouse.Click(top.middle.button);
}
}
If that does not work, because middle is also not available, then use top.Find();.
To learn more about which controls are available or not, try code like this and observe which parts of the screen are highlighted with blue boxes.
for(i = 0; i < 5; i++)
{
top.DrawHighLight();
top.middle.DrawHighLight();
top.middle.control.DrawHighLight();
if(top.middle.control.Exists)
{
mouse.Click(top.middle.button);
}
}
Use TryFind() instead, and set the searchTimeout.
You can use Inspect/UISpy to check the RuntimeId of the control. I think it's kind of controls' version described in AdrianHHH's reply.
But, what confuses me most is that I can use the found control in the first time, in the following loops, Although my application is restarted.
Related
=======================================================
QProgressBar* pbar = new QProgressBar(this);
pbar->setMinimum(0);
pbar->setMaximum(0);
pbar->show();
for (int i = 0; i < 10000; i++) {
qDebug() << "=====flag1======";
}
pbar->close();
===========================================================
I want the ProgressBar show busy when qDebug() message, but there is no effect, the QProgressBar was blocked and close when the loop finished.
Does anyone know how to solve this problem? thank you!
Yes GUI Is Blocked, becose 10 000 it's a lot of time.
Use QThread http://doc.qt.io/qt-4.8/qthread.html .
void My_Thread::run() {
for (int i = 0; i < 1e4; i++) {
if (i % 100 == 0) {
emit UpdateProgressBar(i);
}
}
}
//In Your SLOT
void MainWindow::UpdateProgressbar(int value) {
ui->progressbar->setValue(value);
}
Main threads is locked by loop before UI appears and UI is updated right after loop ends.
If you want to see progress bar you can add QApplication::processEvents(); inside the loop. It's not the best solution but it will work.
To alow any widget to appear event loop has to be processed.
Since you have full control over main thread its event loop is not able to process events which will show and update QProgressBar.
One way to fix if, which is quick but crapy is add to your loop QApplication::processEvents(); which process evens of event loop.
Ofcaource you should also call bar->setValue(i);.
Proper way to do it is asynchronous programing which is using signals and slots. You didn't provide any details about your actual problem so can't provide good solution.
I am wondering about how concurrency can be expressed without an explicit thread object, not the implementation, which probably would use threads or thread pools, but the language design related issues.
Q1: I wonder what would be lost if there was no thread object, what couldn't be done in such a language?
Q2: I also wonder about how this would be expressed, what ways were proposed or implemented as alternatives or complements to threads?
one possibility is the MPI-programm-model (GPU as well)
lets say you have the following code
for(int i=0; i < 100; i++) {
work(i);
}
the "normal" thread-based way would be the separation of the iteration-range into multiple subsets. So something like this
Thread-1:
for(int i=0; i < 50; i++) {
work(i);
}
Thread-2:
for(int i=50; i < 100; i++) {
work(i);
}
however in MPI/GPU you do something different.
the idea is, that every core execute the same(GPU) or at least
a similar (MPI) programm. the difference is, that each core uses
a different ID, which changes the behavior of the code.
mpi-style: (not exactly the MPI-syntax)
int rank = get_core_id();
int size = get_num_core();
int subset = 100 / size;
for (int i = rank * subset;i < (rand+1)*subset; i+) {
//each core will use a different range for i
work(i);
}
the next big thing is communication. Normally you need to use all of the synchronization-stuff manually. MPI is message-based, meaning that its not perfectly suited for classical shared-memory modells (every core has access to the same memory), but in a cluster system (many cores combined with a network) it works excellent. This is not only limited to supercomputers (they use basically only mpi-style stuff), but in the recent years a new type of core-architecture (manycores) was developed. They have a local so called Network-On-Chip, so each core can send/receive messages without having the problem with synchronization.
MPI contains not only simple messages, but higher constructs to automatically scatter and gather data to every core.
Example: (again not MPI-syntax)
int rank = get_core_id();
int size = get_num_core();
int data[100];
int result;
int results[size];
if (rank == 0) { //master-core only
fill_with_stuff(data);
}
scatter(0, data); //core-0 will send the data-content to all other cores
result = work(rank, data); // every core works on the same data
gather(0,result,results); //get all local results and store them in
//the results-array of core-0
an other solutions is the openMP-libary
here you declare parallel-blocks. the whole thread-part is done by the libary itself
example:
//this will split the for-loop automatically in 4 threads
#pragma omp parallel for num_threads(4)
for(int i=0; i < 100; i++) {
work(i);
}
the big advantage is, that its fast to write. thats it
you may get better performance with writing the threads on your own,
but it takes a lot more time and knowledge about synchronization
I am writing an uwp program, you may treat it as a drawing segments program:
It is only allow to draw segments horizontal or vertical.
a new segment must start at an old segment's vertex, and there are two situation not allowed in this program:
1.overlap.
2.intersection.
Here is my code to judge if two segments are cross over each other，Here is my code :
(I use a for loop to select all of segments I have already created, "line[]" stored all the segments I have already created and "ln" stored a random new segment, it will add the new segment to "line[]" if no erro occurs)
for (int l = 0; l < i - 1; l++)
{
if (ln.getY1() == ln.getY()&&line[l].getX()==line[l].getX1())
{
if(line[l].getX()>=Math.Min(ln.getX(),ln.getX1())&&line[l].getX()<=Math.Max(ln.getX(), ln.getX1())&&ln.getY()>=Math.Min(line[l].getY(),line[l].getY1())&&ln.getY()<= Math.Max(line[l].getY(), line[l].getY1()))
{
sameIslandCount++;
}
}
else if (ln.getX1() == ln.getX()&&line[l].getY()==line[l].getY1())
{
if(ln.getX()>=Math.Min(line[l].getX(),line[l].getX1())&&ln.getX()<=Math.Max(line[l].getX(), line[l].getX1())&&line[l].getY()>=Math.Min(ln.getY(),ln.getY1())&& line[l].getY() <= Math.Max(ln.getY(), ln.getY1()))
{
sameIslandCount++;
}
}
}
but when I test this program, it stuck in this screen:
but if I delete all the equal symbol, the program can run successfully. Can anyone tell me how to improve? sorry about my English, hope you can understand what I mean:p
It seems that I have a problem with Linux IO performance. Working with a project I need to clear whole the file from the kernel space. I use the following code pattern:
for_each_mapping_page(mapping, index) {
page = read_mapping_page(mapping, index);
lock_page(page);
{ kmap // memset // kunmap }
set_page_dirty(page);
write_one_page(page, 1);
page_cache_release(page);
cond_resched();
}
All works fine but with large files (~3Gb+ for me) I see that my system stalls in a strange manner: while this operation is not completed I can't run anything. In other words, all the processes that exists before this operation runs fine, but if I try to run something while this operation I see nothing until it completed.
Is it a kernel's IO scheduling issue or may be I missed something? And how can I fix this problem?
Thanks.
UPD:
According to Kristof's suggestion I've reworked my code and now it looks like this:
headIndex = soff >> PAGE_CACHE_SHIFT;
tailIndex = eoff >> PAGE_CACHE_SHIFT;
/**
* doing the exact #headIndex .. #tailIndex range
*/
for (index = headIndex; index < tailIndex; index += nr_pages) {
nr_pages = min_t(int, ARRAY_SIZE(pages), tailIndex - index);
for (i = 0; i < nr_pages; i++) {
pages[i] = read_mapping_page(mapping, index + i, NULL);
if (IS_ERR(pages[i])) {
while (i--)
page_cache_release(pages[i]);
goto return_result;
}
}
for (i = 0; i < nr_pages; i++)
zero_page_atomic(pages[i]);
result = filemap_write_and_wait_range(mapping, index << PAGE_CACHE_SHIFT,
((index + nr_pages) << PAGE_CACHE_SHIFT) - 1);
for (i = 0; i < nr_pages; i++)
page_cache_release(pages[i]);
if (result)
goto return_result;
if (fatal_signal_pending(current))
goto return_result;
cond_resched();
}
As the result I've got better IO performance, but still have problems with huge IO activity while doing concurrent disk access within the same user as caused the operation.
Anyway, thanks for the suggestions.
In essence you're bypassing the kernels IO scheduler completely.
If you look at the ext2 implementation you'll see it never (well ok, once) calls write_one_page(). For large-scale data transfers it uses mpage_writepages() instead.
This uses the Block I/O interface, rather than immediately accessing the hardware. This means it passes through the IO scheduler. Large operations will not block the entire systems, as the scheduler will automatically ensure that other operations are interleaved with the large writes.
I am trying to remove all the subviews from a UIView. I tried the following to no effect:
for (int i = 0; i < this.Subviews.Length; i++)
{
this.Subviews[i].RemoveFromSuperview ();
}
Just tested this and it worked for me. (Although your code also looks good to me...)
foreach (UIView view in tableView.Subviews) {
view.RemoveFromSuperview();
}
If it doesn't work for you, there might be something that prevents the subviews from being removed.
The problem with your sample is how you built the loop.
When you remove the view at 0, the Subviews array is one element shorter, and element 1 becomes element 0 on the next iteration. Your i variable on the other hand keeps growing, so you end up skipping view 1.
Try forcing a refresh of the view afterward, or invoking the Remove call specifically on the main thread.
If you absolutely need to use an for loop, this will do
for (int i = this.Subviews.Length - 1 ; i > 0 i--)
{
this.Subviews[i].RemoveFromSuperview ();
}