I have problem with Intellisense on Visual Studio 2010.
Intellisense doesn't suggest arguments for class constructors. Although it works fine with class methods.
class Window
{
private:
WindowImpl *Impl;
public:
static unsigned int WindowCount;
Window();
Window(unsigned int width, unsigned int height, const std::string &title, int x, int y, unsigned int style);
void Create(unsigned int width, unsigned int height, const std::string &title, int x, int y, unsigned int style);
~Window();
void Destroy();
};
Error: no instance of constructor matches the argument list
Window mainWindow(100, 200 ...
Works fine
mainWindow.Create(100, 200 ...
No compilation error, but Intellisense doesn't show (does not suggest) arguments for constructor and shows this error.
I figured out that problem exists with all classes. I hope screenshot will help understand what I mean. I have tried Visual Assist X and it doesn't help. Thanks in advance.
I have tested your example in my VS 2010 and Intellisense is working fine for both lines. Note that if the function is overloaded, IntelliSense shows the first variant, and you can press up/down arrows to see other.
IntelliSense is known to get stuck sometimes, not indexing some classes or showing wrong results. In such a case you can close your project and delete intellisense database. When you reopen the project, it gets created from scratch, hopefully with more success.
Also if you are writing much C++ in VS, consider using Visual Assist X, which substitutes much of IntelliSense functionality, but performs much better. (I am not affiliated with Tomato Software, just in love with the tool.)
Related
I have a global enumeration
enum class CColour{
BLACK,
WHITE,
GOLD
};
that has its own headerfile CColour.h wich is included in stdafx.h
I was trying to fix some bugs (EDIT: I'm done with that) and encountered the following:
#include "stdafx.h"
using namespace System;
int main(array<System::String ^> ^args)
{
[...]
CColour colour1 = WHITE;
[...]
}
I've set a watch to colour1 in Visual Studio, and I have some other functions using CColour too, but in the watch it is always displayed as <undefined value> with no type specifier. (and a small lock next to the icon, don't know if that's relevant)
this seems strange because every function that uses CColour works perfectly fine.
can anybody explain why that is and how to fix it?
I'm developing a Qt 4.8.4 GUI application targeting Windows 7. I'm trying to implement the "Solving a Problem Step by Step" approach to keep the GUI responsive during a long-running computation, which is nicely divisible into many small steps.
Here is a minimal working example of this technique:
Computation.h
#pragma once
#include "QtCore/QCoreApplication"
#include "QtCore/QDebug"
#include "QtCore/QObject"
#include "QtCore/QTimer"
class Computation : public QObject {
Q_OBJECT
public:
Computation() : amount_(0) {}
public Q_SLOTS:
void start() {
amount_ = 100000;
QTimer::singleShot(0, this, SLOT(calculate()));
}
private Q_SLOTS:
void calculate() {
if (--amount_ > 0) {
qDebug() << "Calculating..." << amount_;
//QCoreApplication::processEvents();
QTimer::singleShot(0, this, SLOT(calculate()));
} else {
qDebug() << "Finished";
}
}
private:
int amount_;
};
main.cpp
#include "Computation.h"
#include "QtCore/QDebug"
#include "QtGui/QApplication"
#include "QtGui/QMainWindow"
#include "QtGui/QPushButton"
int main(int argc, char* argv[]) {
QApplication app(argc, argv);
Computation computation;
QMainWindow window;
QPushButton button(&window);
button.setText("Test");
QObject::connect(&button, SIGNAL(clicked()), &computation, SLOT(start()));
window.show();
return app.exec();
}
There's also a CMakeLists.txt for this example in case anyone wants to try it out.
Now, on to the actual problem: when the computation is running, certain GUI interactions lead to a lockup of the mouse. The cursor can still be moved, but clicking on any part of the desktop has no effect at all in this state. The computation still goes on. The only way to escape this lockup is to switch to another application with the keyboard (e.g. Alt+Tab, pressing the Windows key, or Ctrl+Alt+Del) or to wait until the computation has finished.
The GUI actions which lead to this state include attempting to move or resize the application's main window. Instead of changing the window's geometry, the mouse lockup explained above happens. However, the window instantaneously jumps to the position is was to supposed to be moved to as soon as the computation finishes (and you didn't switch to another window in between).
Opening the system menu (by clicking on the application symbol in the title bar) also leads to similar behavior, but this time only the application (including the system menu) is indifferent to mouse clicks.
I tried to work around this problem by issuing QCoreApplication::processEvents() in my calculate() method (commented line in the above example). This only helped a little: instead of locking up the mouse every time one tries to move or resize the window, you now have to do it about 3-5 times to trigger the behavior. Different combinations of QCoreApplication::sendPostedEvents() and QCoreApplication::flush() didn't help either.
How can I solve this problem? Is this a known Qt bug and/or is there a workaround?
If you need to make an application multi-threaded, you can use Qt's slots and signals architecture. Just emit a signal from your thread when something changes. Then in your UI thread, connect a slot to the signal from your thread:
Qt: Background thread refreshing UI thread
Using QThread is definitely a better strategy than chunking the computation and trying to do everything in one thread.
Then in the calculate thread, use a timer every 1/15 sec (for example) to call a signal that has been connected to a slot in the main thread, which informs the UI to update any data you want to see from the calculations.
I have a local array and I'd like to take a look at the contents with Xcode 4.3.2. The array does not appear in the Variable View window, so I don't know how I can access it, either through the Variable View window or through a memory window. I can create a pointer to the array and view memory that way, but that seems like unnecessary work. Other variables are working just fine. Here's the code:
int width = 32;
int height = 24;
unsigned int testData[width * height];
unsigned int *ptr = &testData[0];
The width, height, and ptr variables appear in the Variable View window, but not testData. What am I missing with Xcode? Thanks!
If you're using LLDB, switch back to GDB. LLDB is still not entirely ready for prime time.
(Edit your scheme, choose the Run action, and in the "Info" tab, you can choose which debugger to use.)
Also: Make sure you are debugging a "debug" build, with no optimizations. The "Optimization Level" build setting should be "None [-O0]". Higher optimization levels can confuse any debugger.
I suspect this just isn't possibly, but it doesn't hurt much to ask.
I am working on 2 branches of the same code, so everything looks pretty identical from the solution explorer. But one is the branch, one is the trunk. I have no visual cues as to which one is open at the moment.
Is there anyway to get Visual Studio 2010 to display some visual clue that this project is different from the other?
Unless you write some sort of plugin, no. I do the same thing often, what I usually do is either make it a habit to double check the path before I work on a file (hover the mouse over the tab in VS).
or, I have two monitors, and if I'm working at the same time on two different branches, I'll have one on the left, and one on the right :-)
I had this same problem a while ago, but could not find anything that solved the problem. I got so frustrated that in the end I wrote a simple add-in for Visual Studio that showed the path of the current solution in the title bar of the window. It was not ideal however as you had to click on a tool window (eg. Solution Explorer) to get it to show, but it worked for what I needed.
The code for the addin if you are interested:
public class Connect : IDTExtensibility2
{
private DTE2 _applicationObject;
private WindowEvents we;
[DllImport("user32.dll")]
private static extern bool SetWindowText(IntPtr hWnd, string lpString);
public void OnConnection(object application, ext_ConnectMode connectMode,
object addInInst, ref Array custom)
{
_applicationObject = (DTE2) application;
we = _applicationObject.Events.get_WindowEvents(null);
we.WindowActivated += WindowActivated;
}
private void WindowActivated(Window GotFocus, Window LostFocus)
{
string path = _applicationObject.Solution.FileName;
if (!string.IsNullOrEmpty(path))
{
SetWindowText((IntPtr) _applicationObject.MainWindow.HWnd, path);
}
}
}
It's a bit crude, but helped me out a lot.
Is there any way to make a MFC DockablePane (from the new Feature Pack) that is docked in a window not able to float or to hide (and even disable the context menu that allows the user to select the states - dockable, float, hide etc.)
What I basically want is to have 3 panes on a window that can change their horizontal dimensions, but not their position inside the window. Any suggestion?
The solution is to extend the CDockablePane and override in this class the following events:
virtual BOOL CanFloat() const;
virtual BOOL CanBeClosed() const;
virtual BOOL CanAutoHide() const;
so that they return FALSE;
for more information see MSDN Customization Tips for the MFC Extensions
Try changing the dwControlBarStyle when you create the window (with CDockablePane::Create).
Another solution is, just call
CBasePane::SetControlBarStyle(AFX_CBRS_RESIZE|AFX_CBRS_CLOSE);