Everyone's raved about how awesome Qt is and I would really love to use it. However, after downloading it and trying to build a little Hello World app, the performance of the Qt Creator slogged to the point of being unusable.
The main problem is when I switch from "Edit" (code-view) to "Design" (form-view), it takes roughly 30-45 seconds for the form to draw every single time I do this. Here is a video of this happening.
Hitting CTRL-R to run my application takes 30-45 seconds to display my application.
If anyone has had these issues, please post a suggestion! I would really love to use Qt.
UPDATE: After closing Qt Creator, I notice that Hg Workbench (Mercurial) takes between 1-2 minutes to open (where it's regularly instant).
I'd suggest you to run the application i.e., qtcreator from a command prompt. Since qDebug will be printing out crucial information about the actions going on, you might have a chance to understand what exactly is causing the slowdown.
Just in case., try the new QtCreator2.5.1 which runs well. Even if this doesn't work, probably there should be something wrong with the OS. Check for any programs that are running in the background which can be choking on the processor.
Related
My application started life as a c++ Console application in VS2019. Code was provided as part of an SDK. Worked perfect. Great response from the manufacturer USB device. Later, I wanted to graduate is to a GUI application, much as I've been doing in VB and c#. Lo and behold, I managed to reconstruct the application in both Qt and Win32 but I'm running into a situation where the application becomes unresponsive and I have no way to tell what's going on.
In the Console application, I have to execute this code to interface with the device AFTER sending a "TakeMeasurement" command :
if (SDK_SUCCESSFUL(sdkError)) {
printf("\nWaiting for measurement to complete...\n");
while (!isMeasureWait) {
if (isDisConnect) break;
this_thread::sleep_for(chrono::milliseconds(1000));
}
}
This code works like a charm! Ater one or two iteration, the device has completed the measurement and I can get to the data easily.
On the Win32 side, I use the exact same code. Only, once control enters the loop, it never returns.
Any idea how I could diagnose the error? I have the impression that the "timing" is critical, between the exact moment where the Measurement command is initiated to the exact moment the instrument signals that it's done, and the data ready to be picked up.
My naive hypothesis is that, in debug mode on both 'platforms', I must be getting some timing differences? Sadly, I can't get more information from the manufacturer in this regard but I suspect I have a small window of time within which the instrument's response can be acted on? And I begin to suspect that, on Win32, that "time" is too long? Compared to on the Console side?
I was thinking of, perhaps, "measuring" that time, in milliseconds? First, on the Console side, to see what kind of delay "works", and then, to see how the delay compares with the Win32 side.
I may be wasting my time and I sure don't mean to waste yours.
How would I go about getting an idea of time elapsed in a c++ application? I'll take a look around VS2019, they have all kinds of "performance" things that popup at run time?
Any help is appreciated.
I am not sure I completely understand what is going on.
Execution of the thread wait loop was not not the culprit.
I'm not 100% sure but what happens is that, in my 'Export data to CSV TEXT file', if I tried to execute the call to :
SetWindowText(hEditMeasure, wMeasurements);
The application always hung. I placed breakpoints right before the call in the code, to trace execution, and it did not strike me at first but, in VS toolbar, there was a "thread" comboBox? With the value showing = DEVICE.DLL? and to its right, the name of my Export function as the Stackframe. In searching for additional information on the setWindowText function, I came accross the reference to use VM_SETTEXT to send to "different application"? Could it be unknowingly I was sending a message to "another thread", the DLL thread? And that's why it hung? I did not know enough to tell. So I started to move the setWindowText line around, ultimately inside the code that is called by the "Measure" button, and it worked!
I'm not out of the woods yet but I feel I'm making progress. Thank you all for your help and patience.
I am really new to programming (actually trying to get this to work for my 1000 level intro C++ class) so I apologize for bad descriptions and lack of terminology.
I am having trouble getting a "Hello World" program to work on Geany. I have followed the instructions here http://wiki.geany.org/howtos/win32/getting-started , pretty much to the letter. My program gets a successful message when I hit compile/build. When I hit execute the terminal pops up but it is blank.
There is a flashing cursor in the spot where I would expect Hello World to be but instead it is blank, and I cannot type anything in the window. From what I've researched I think it may be a similar problem from here How do you make Execute do anything in Geany? but searches on changing the terminal form to work for windows has not yielded any results.
In fact, I have not found much help for Geany on windows at all, so if there is a better set of software to use that is pretty basic I would be interested, I am only really attached to Geany because that is what we will be using in class (on a Linux operating system)
Thanks for the help!
John
Avast Antivirus does, in fact, cause Geany to fail execution of the program. Windows 10 Pro 64-bit using Geany 1.26 full installer with MinGW. I just shut down shields for 10 mins and this allowed the program to execute.
Thanks.
I'm working on an application that uses multiple threads to process its data. The app is developped in C++ (Intel C++ comp. 9.1) and uses OpenMP. It is a 64 bit app running on Win7.
The problem is that when I run it during day, it runs correctly. But when I run it during night after the screen has been locked, it enters in a forever loop after a few processes.
To be more precise, the app is called many times for different files to process. The calls are done within a batch file (no problem there).
I found that it enters in the forever loop about 2 hours after the lock screen occurs.
I disabled all power saving settings. But nothing changed.
It is not very clear as description but the reason is that I don't have a clue about the source of the problem. I just hope someone among you could have had the same problem (and found a fix!). If you want more details, just let me know.
Any idea? Thanks in advance!
As my tests go on, I installed the same setup (but in release rather than debug version) on another computer. I ran into the same problem after 20 minutes (after the screen lock) with another set of data. I ran the same data on my own computer (which is not locked) and everything was fine.
I'm mystified!
Are you giving a thread priority that is taking control of the application?
Also, I would suggest taking running it through some kind of profiling, such as VTune as it can point out potential odd cases that could be causing an issue for you. (There is a free evaluation that you can try).
after I compiled my project in C++ (VisualStudio) around 3-4 times, I can do it anymore due to LNK1168 that stands for "VisualStudio can't write into the exe". I've looked up in my TaskManager, the exe is NOT running. Normally I have to wait for like 5 minutes but that isn't a real solution. Any ideas?
ProcessExplorer just tells me, that the handle is invalid and though can't be closed. It remains open all the time...
First thing that comes to mind is to use ProcessExplorer to figure out what process is keeping the file open. Download and start up the tool en select Find from the menu. Enter the (partial) file name and it should show up in the search results. Double click to jump to the process and file handle in the main application window.
I'm guessing Visual Studio is the culprit.
Fortunately, you can also use Process Explorer to close the handle. Right-click and choose Close Handle.
Note that it's not a good idea to go around closing file handles on a regular basis. However, whenever you're in a pickle it can really help solve annoying problems.
If I recall correctly, a similar problem existed way back in VS 6. It had to do with incremental compilation. For a more structural solution, try doing a full rebuild from time to time or disabling incremental compilation all together.
I have been experiencing exactly the same problem (For C# and C++). I have just discovered that having the Application Experience Service disabled seems to cause EXPLORER.EXE To keep .exe files hanging around (locked by the SYSTEM) for several minutes after running that executable.
The solution to this problem, for me at least, was to re-enable the Application Experience service. (I had originally disabled it since it seemed unnecessary - Apparently I was wrong!)
Your exe might still be running. Stop it before recompiling it.
I'm developing a QT application with QTCreator (and QT 4.5.3) on Arch Linux. I'm using KDE 4.3
The project is basically a GUI that let you insert a url and make some web requests to give the user some data back.
The web requests are asynchronous.
I've encountered a weird problem.
If I start the application the first time and click on the button that launches the web requests, it crashes.
On the second time it works as expected.
The third and the fourth time it returns just one of the 900 values I was expecting.
What's strange is that on Windows (and QT 4.6) is working always fine..
Have you ever seen such a thing?
Thanks in advance for your information
Best regards
I've never seen anything exactly like this, but I have seen different behaviours between Linux and Windows where the Windows code seemed to work. In my experience, the code is almost always wrong - it's just much easier to catch it when you run in Linux.
I have two suggestions to make:
run with Valgrind: this will catch the obvious flaws
link with the Qt debug libs (usually QtCored.so, QtGuid.so on Linux)
And a third: look very carefully at the web requests responses in Linux / Windows, possibly in a diff-scanner. Any differences might point you in the right direction
I'd say that has something to do with cookies.
Try to create the smallest possible application that reproduces that bug and then try to determine, if it's your or Trolltech's code that crashes.
The problem was related to an array of elements which weren't set in time