Does Qt has something to offer for the positioning of the tooltip-like windows? (or any types of windows/widgets actually).
I want to be able to update the position of the window automatically, so that it always stays on the screen (or at least fits it as much as possible).
An example of the behaviour I want can be seen in the standard Windows tooltips in the notification area. If the tooltip is big and it has some part of it going off the screen, it gets automatically repositioned.
Obviously, I can write the code myself, but I'm looking for something that has already been written.
I don't know if Qt has one single function that ensures a widget is totally inside of the screen. But with QDesktopWidget it's probably trivial to do.
void function RestrainWidgetToScreen(QWidget * w)
{
QRect screenRect = QDesktopWidget::availableGeometry(w);
if(w->frameGeometry().left() < screenRect.left()) {
w->move(screenRect.left() - w->frameGeometry().left(), 0);
} else if(w->frameGeometry().right() > screenRect.right()) {
w->move(screenRect.right() - w->frameGeometry().right(), 0);
}
if(w->frameGeometry().top() < screenRect.top()) {
w->move(0, screenRect.top() - w->frameGeometry().top());
} else if(w->frameGeometry().bottom() < screenRect.bottom()) {
w->move(0, screenRect.bottom() - w->frameGeometry().bottom());
}
}
Related
I'm currently developing a notepad and I've found a problem.
Basically in a QTextEdit I have different text with different point sizes. So if I want to change the font of these ones their point size will reset to the one of the textbox.
I will make an example with images.
before:
after:
As you can see I changed the font to times new roman but the point size changed.
This is the code:
void MainWindow::on_fontComboBox_currentFontChanged(const QFont &f)
{
ui->fontComboBox->setFont(f);
QTextEdit *edit = getTabTextEdit();
if(ui->tabWidget->currentWidget() == ui->tab_1)
{
ui->edit->setCurrentFont(f);
}
else
{
edit->setCurrentFont(f);
}
}
How can I solve this?
Store the fontPointSize before you change fonts and reapply it with setFontPointSize. I don't think there is a way to retain the size.
To whom it may concern,
GetTextExtentPoint and GetTextExtentPoint32 is giving me a bad day.
They are the only method MSDN offers for measuring text but they have two flaws, but nobody else seems to have these problems.
Firstly, they dont take into account newline. They treat the measurement as one long one liner.
Secondly and most importantly, they are causing aliasing when I do DrawText(). I am using ClearType for HFONT but still get aliasing text being drawn.
Kindly let me know precisely what is the problem. Or I might have to create my own measuring text function.
EDIT_________
// note font is created with CLEAR_TYPE_QUALITY
// so it should be antialiased
HFONT createFont(const char *face_name,int height)
{
return CreateFont(height,cHeight,0,0,0,FW_NORMAL,false,false,false,0,0,0,CLEAR_TYPE_QUALITY,0,face_name);
}
RECT box{0,0,640,480);
POINT pos{};
HFONT font = createFont("MyFavouriteFont",30);
HDC canvas = CreateCompatableDC(NULL);
HBITMAP bmp = CreateCompatibleBitmap(NULL,640,480);
SelectBitmap(canvas,bmp);
SelectFont(canvas,font);
SelectBrush(canvas,GetStockObject(DC_BRUSH));
SetDCBrushColor(RGB(255,255,255));
SetBkMode(TRANSPARENT);
SIZE measureText_Msdn(const char *s,HDC font)
{
SIZE sz;
GetTextExtentPoint(font,s,strlen(s),&sz);
return sz;
}
SIZE measureText_Custom(const char *s,HDC font)
{
SIZE sz;
TEXTMETRICSA metrics;
INT char_width, line_width;
// get char height
GetTextMetrics(font,&metrics);
while(*it)
{
if(*it == '\n' || *it == '\r')
{
if(line_width > sz.cx) sz.cx = line_width; // sz.cx stores max width
sz.cy += metrics.tmHeight;
line_width = 0;
}
else
{
GetCharWidth32(font,*it,*it,&char_width);
line_width += char_width;
}
++it;
}
if(line_width > sz.cx) sz.cx = line_width;
if(line_width > 0) sz.cy += metrics.tmHeight; // If there are no chars on this line, the line has no size
return sz;
}
void drawText(HDC dest_ctx)
{
auto s = ,"Text will look blocky";
measureText_Msdn(s,font);
// or measureText_Custom(s,font); will cause font to look blocky and ugly
// If you comment out measureText_* text will be drawn smooth.
FillRect(canvas, &box,(HBRUSH)GetCurrentObject(canvas,OBJ_BRUSH));
DrawTextA(canvas,s,-1,&box,DT_LEFT);
BitBlt(dest_ctx,pos.x,pos.y,box.right,box.bottom,
canvas,0,0,SRCCOPY);
}
SOLUTION_____
I have posted a solution as an answer. I dont like to have to do it. As I said earlier, nobody else seems to have this problem so nobody else would need the solution.
As I said earlier nobody seems to get blocky text when using any of the text measuring functions. I get it when using any of them.
What I noticed is that calling these functions require a context, and the functions seems to be currupting the context. Even if I select a new font into the context I still get blocky text output.
Thus I create a context on the fly and add the desired font into it. And measure with that context, collect the result and delete that context. I tested this and my text are drawn smooth as my original context is unaffected.
Reasons I hate this method:
- I am afraid of the expense of creating and deleting context on the fly.
- I dont think GetTextExtent should currupt my context in the first place.
If you guys have a better way, or know my problem, or why I shouldnt be having this problem kindly post.
EDIT_________
After looking at using keyboard tutorial on MSDN, I saw where the author using a window context instead of memory context for calls to GetTextExtent. It appears that GetTextExtent and the other measurement functions are only meant to be used with window contexts. Which is perfectly fine for me as I dont like Creating Memory Context anyhow.
Using C++ Builder 2009
I have a custom control that inherits from TCustomControl, on which I paint several squares (TRect) with content etc.
I now wanted to show Hint as I hover over every square, but I'm not sure how to implement this best.
I attempted to simply use TCustomControl's ShowHint, and change Hint as I hover over the squares, but the problem is that the control doesn't show hint anymore after it first disappears, unless I leave the control and come back to it.
I hoped I could simply 'reset' it's state while hovering from one square to another but it doesn't work.
Assuming my approach is wrong to start with, kindly let me know what I should do to get the desired effect ?
if (State == rsHover && Item->FState != rsHover) // Not in the rsHover state yet, but going to
{
if (Item->Hint.Length())
{
if (ShowHint)
{
// Attempt to reset Hint's internal working, to no avail
Hint = L"" ;
ShowHint = false ;
}
Hint = Item->Hint ;
ShowHint = true ;
}
else
{
ShowHint = false ;
}
}
else if (State != rsHover)
{
ShowHint = false ;
}
The correct way to implement this feature is to make your component handle the CM_HINTSHOW message. The message's LParam value will be a pointer to a THintInfo record, whose fields you can freely modify as needed (in particular, HintStr and CursorRect).
To access the record, you can either
type-cast the LParam directly to THintInfo*.
type-cast the entire TMessage to TCMHintShow, and then access its HintInfo field.
By defining your own CursorRect rectangles, you can "[divide your control] into several hint regions", each with a different HintStr value. The CursorPos field indicates the mouse's current position within the control. When the mouse moves outside of the current CursorRect, the control will receive a new CM_HINTSHOW message, and you can update the CursorRect and HintStr fields as needed.
I am trying to do a little game, and in my game I have some squares and when the user click on these squares, they got highlighted. To achieve this effect I am using glutMouseFunc with glutTimerFunc.
When the user clicks on the screen I pick the pixel and identify the square I need to highlight. Once the square is identified I call glutTimerFunc. The function registred with glutTimerFunc increase the value of each component of color by 0.01 until they reach one max value defined by me, then this value goes back to a minimum value.
glutTimerFunc execute in 60 milliseconds and I get a almost smooth shine effect.
My problem is, if I click on two squares very fast, the effect starts on the first square, but don't finish, so the square remains highlighted and the second squares do the entire effect. If I click like a crazy man on every square, all of them got highlighted.
How can I make this effect of shining terminate even if I click on other square?
Here is a snippet of code
void Memoria::shineEffect(GLint value) {
if(value == 1) {
for(GLint i = 0; i < 3; i++) {
if(colors[selectedSquare][i] > 0) {
colors[selectedSquare][i] += COLOR_INCREASE;
if(colors[selectedSquare][i] >= MAX) {
colors[selectedSquare][i] = MAX;
value = -1;
}
}
}
glutTimerFunc(FPS, timeWrapper, value);
}
else {
if(value == -1) {
for(GLint i = 0; i < 3; i++) {
if(colors[selectedSquare][i] > 0) {
colors[selectedSquare][i] -= COLOR_INCREASE;
if(colors[selectedSquare][i] <= MIN) {
value = 0;
colors[selectedSquare][i] = MIN;
}
}
}
glutTimerFunc(FPS, timeWrapper, value);
}
}
}
timeWrapper calls shineEffect if the value passed in the parameter is 1 or -1.
You want the shineEffect function to go through one highlight loop at least, and then stop if the highlighted item has changed. It's more a UI code design issue rather than an OpenGL or GLUT one.
The mechanic you need to implement is pretty straightforward:
install once for all an updateHighlights function with glutTimerFunc: this function will be responsible of updating the highlights of all the clicked elements,
create a queue of elements: each time an element has been clicked, add it to the queue,
The task performed by the updateHighLights function should be as follow:
if the queue contains one element, keep cycling its highlight as you already do in your program
if the queue contain more than one element, for each element in the queue,
step the highlight cycle
if the cycle is over, and the element is not the last one, remove the element from the queue
Here's another perhaps more flexible take on your problem.
The Glut event loop machinery is very simple design: there's only one hook to put your "idle work" code, so it's probably more flexible to install a function there which calls a list of others functions. That list could be then modified with a set primitive, to install or remove specific tasks to perform during idle time. This could be much more flexible than the "one function" approach of GLUT.
For instance, you could isolate your current highlight code in one function with a struct containing the element to highlight, and have the function remove itself from the list when its element is done through a highlight cycle and isn't active anymore.
Since you are using C++, it should be easy to bundle all these functionalities in classes:
one class for the list of idle tasks
one base class for idle tasks
one derived idle task class for the purpose of highlighting a square (with fields for the square and for the active status)
one class to keep track of the active square, so that it may be easily deactivated and replaced by the new active one. This one would be accessed by the glutMouseFunc function.
I know that in order to kill invaders in C++, I need to make a collider.
However, nothing will ever kill the invaders in that game.
Here's the code in the header:
bool DoCollision(float Xbpos, float Ybpos, int BulWidth, int BulHeight, float Xipos, float Yipos, int InvWidth, int InvHeight);
This is the function I'm initializing:
bool Game::DoCollision(float Xbpos, float Ybpos, int BulWidth, int BulHeight, float Xipos, float Yipos, int InvWidth, int InvHeight) {
if (Xbpos+BulWidth < Xipos || Xbpos > Xipos+InvWidth) return false;
if (Ybpos+BulHeight < Yipos || Ybpos > Yipos+InvHeight) return false;
return true;
}
And this is what happens if somebody presses the space key:
if (code == 57) { //Space
myKeyInvader.MeBullet.Active = true;
myKeyInvader.MeBullet.Xpos = myKeyInvader.Xpos + 10;
myKeyInvader.MeBullet.Ypos = myKeyInvader.Ypos - 10;
myKeyInvader.MeBullet.yvuel = 0.2;
myKeyInvader.MeBullet.BulletP->CopyTo(m_Screen,myKeyInvader.Xpos,myKeyInvader.Ypos);
if (DoCollision(Invaders[counter].MyBullet.Xbpos,Invaders[counter].MyBullet.Ybpos,Invaders[counter].MyBullet.BulWidth,
Invaders[counter].MyBullet.BulHeight,Invaders[counter].Xipos,Invaders[counter].Yipos,Invaders[counter].InvWidth,Invaders[counter].InvHeight)) {
//myKeyInvader.Ypos = 100;
Invaders[counter].Active = false;
printf("Collide!\n");
}
}
Does anybody know what's going wrong?
The problem isn't C++. The problem is how you are using it. The only way you'll get a kill with your code as written is if the invader is right on top of you. But that's too late. The alien invader has already killed you.
What you need to do is make those bullets into objects that you propagate over time, just like your invaders are objects that you propagate over time. The response to the user pressing a space key should be to add a new instance of a bullet to the set of active bullets. Each of those active bullets has a position that changes with time. On each time step, you should advance the states of the active invaders per the rules that dictate how invaders move and advance the states of the active bullets per the rules that dictate how bullets move. Remove bullets when they reach the top of the screen, and if an alien invader reaches the bottom of the screen, game over.
After propagating, removing off-screen bullets, and checking for game over, you want to check for collisions between each of the N bullets with each of the M invaders. When a collision is detected, remove the bullet from the set of active bullets and delete the alien invader from the set of active invaders. And of course you'll want some nifty graphics to show the user that another alien bit the dust.
Aside: Being an NxM problem, this check might be the biggest drain on CPU usage. You can speed this up with some simple heuristics.
You could manage the collections of alien invaders and bullets yourself, carefully using new and delete so as to prevent your invaders and bullets from killing your program with a memory leak. You don't have to do this. C++ gives you some nifty tools to manage these collections. Use one of the C++ standard library collections instead of rolling your own collection. For example, std::vector<AlienInvader> invaders; or std::list<AlienInvader> invaders, and the same for bullets. You'll be deleting from the middle a lot, which suggests that std::list or std::deque might be more appropriate than std::vector here.
You test the collision for the fired item just when they are created
Shouldn't be the test collision done in the main loop for each existing item at each frame ?
Don't worry, C++ has got all you need to kill invaders :)))
It's not easy to give advice based on so little code, but here the only logical error seems to be you test for collision only when space is pressed; you should test for it in an outside loop probably:
if (code == 57) { //Space
myKeyInvader.MeBullet.Active = true;
myKeyInvader.MeBullet.Xpos = myKeyInvader.Xpos + 10;
myKeyInvader.MeBullet.Ypos = myKeyInvader.Ypos - 10;
myKeyInvader.MeBullet.yvuel = 0.2;
myKeyInvader.MeBullet.BulletP->CopyTo(m_Screen,myKeyInvader.Xpos,myKeyInvader.Ypos);
}
From a logical point of view, pressing Space should fire a bullet: the starting position for the bullet is set, and so is its speed on the Y axis (so that it goes up).
The code that check for collision should go outside of this if block. In fact, this block of code is executed only if you're still pressing space -that is: still firing-. Should collision be checked only if you're "still firing"? Do the fact that you fired a bullet and started waiting for it to destroy the invader interfere in some way with the fact that this bullet can reach the invader and, indeed, destroy it? Of course not!
if (DoCollision(Invaders[counter].MyBullet.Xbpos,Invaders[counter].MyBullet.Ybpos,Invaders[counter].MyBullet.BulWidth,
Invaders[counter].MyBullet.BulHeight,Invaders[counter].Xipos,Invaders[counter].Yipos,Invaders[counter].InvWidth,Invaders[counter].InvHeight)) {
//myKeyInvader.Ypos = 100;
Invaders[counter].Active = false;
printf("Collide!\n");
}
You want collision to be checked in an outside loop, the same that probably also contains the checks for key presses. In this way, even if you're just looking at the screen and waiting, the program keeps testing the condition and, when it's fulfilled, code associated with the event of collision is executed (that is: an invader is "inactivated").
You say //Space , is that what it is or should it be 32 (if ASCII) instead of 57? Does the program flow into the if==57 block?
Your code looks fine, but you need two loops around the collision checker: one for checking all invaders (not just one of them) and another one to check at every bullet position along its trajectory, not just the moment when it leaves the gun.
I will assume we have an auxiliary function that moves the bullet and returns whether it is still inside the screen:
bool BulletIsInScreen();
Then we can write the loops:
if (code == 57) { // Space
while (BulletIsInScreen()) {
for (size_t i = 0; i < counter; ++i) { // counter is the number of invaders,
// according to your comment to your own answer
myKeyInvader.MeBullet.Active = true;
myKeyInvader.MeBullet.Xpos = myKeyInvader.Xpos + 10;
myKeyInvader.MeBullet.Ypos = myKeyInvader.Ypos - 10;
myKeyInvader.MeBullet.yvuel = 0.2;
myKeyInvader.MeBullet.BulletP->CopyTo(m_Screen,myKeyInvader.Xpos,myKeyInvader.Ypos);
if (DoCollision(Invaders[i].MyBullet.Xbpos, Invaders[i].MyBullet.Ybpos,
Invaders[i].MyBullet.BulWidth, Invaders[i].MyBullet.BulHeight,
Invaders[i].Xipos, Invaders[i].Yipos,
Invaders[i].InvWidth, Invaders[i].InvHeight)) {
//myKeyInvader.Ypos = 100;
Invaders[i].Active = false;
printf("Collide!\n");
}
}
}
}
Now this should work as expected.