I have the following piece of GTK3 code:
(...)
cmd_bar = gtk_entry_new();
gtk_editable_set_editable(GTK_EDITABLE(cmd_bar), TRUE);
gtk_entry_set_visibility(GTK_ENTRY(cmd_bar), TRUE);
gtk_widget_grab_focus(GTK_WIDGET(cmd_bar));
gtk_grid_attach (GTK_GRID (grid), GTK_WIDGET(cmd_bar), 0, 1, 2, 1);
gtk_widget_show(cmd_bar);
(...)
It shows the GtkEntry correctly, however it doesn't show any input from keyboard. If I paste some string it's accepted normally.
How can I resolve this issue?
I had the same issue when I ported my application from GTK3 to GTK4, same behavior that I was able to paste and cut text in the entry but not being able to focus or freely insert text with my keyboard.
Already in my GTK3 application I had on a few widgets incorrectly set the "can-focus" property to "False" by mistake in my templates (with glade) and when porting to GTK4 they seem to have caused issues.
At first I didn't think the "can-focus" property could be the issue because my GtkEntry had it set to TRUE, the issue was that one of it's parent containers had the value set to FALSE.
Hopefully this was the issue for you as well, if it's not hopefully it's an solution for someone else.
According to the GtkWidget documentation:
[gtk_widget_grab_focus] Causes widget to have the keyboard focus for the GtkWindow it's
inside. widget must be a focusable widget, such as a GtkEntry;
something like GtkFrame won't work.
More precisely, it must have the GTK_CAN_FOCUS flag set. Use
gtk_widget_set_can_focus() to modify that flag.
The widget also needs to be realized and mapped. This is indicated by
the related signals. Grabbing the focus immediately after creating the
widget will likely fail and cause critical warnings.
For an explanation of realize and map, check "Those “realize” & “map” widget signals".
Related
I have a very simple code, wich create a GtkWindow and place in it a GtkButton.
window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
gtk_widget_set_size_request(_window, 800, 450);
gtk_window_set_decorated(GTK_WINDOW (_window), FALSE);
gtk_window_set_position(GTK_WINDOW (_window),GTK_WIN_POS_CENTER_ALWAYS);
gtk_window_set_resizable(GTK_WINDOW (_window), FALSE);
_startbutton = gtk_button_new_with_label("myLabel");
gtk_container_add(GTK_CONTAINER(_window), _startbutton);
gtk_widget_show_all(_window);
Yet, this doesn't work as expected because the button fills the whole window.
I tried to find a way to change the button size, but all the methods that i found use some methods that are deprecated...
Can someone explain to me the way to do this ?
Because the GtkButton is the only control in the GtkWindow, it will be given the entire area of the GtkWindow to fill. If you want to do anything more complicated, you will need to use layout containers like GtkBox and GtkGrid to explicitly lay out the button, usually in relation to other controls that you will also have in the window.
Once you do lay out your controls, you can use expansion and alignment to control how the button makes use of its allotted space.
So I have a window, and I have coded it so that during run-time it can enter and exit full-screen mode. Entering full-screen works, but exiting places the window tile bar in reverse order.
Exit full screen code:
SetWindowLongPtr(hWnd, GWL_EXSTYLE, WS_OVERLAPPEDWINDOW);
SetWindowPos(hWnd, HWND_TOPMOST, 0, 0, 640, 480, NULL);
InvalidateRect(hWnd, NULL, TRUE);
Picture of the result: https://www.dropbox.com/s/p15eltz7b2hxx4y/window.png?dl=0
I tried using GWL_STYLE instead of GWL_EXSTYLE but that works even worse, with the window being visible but clicking anything on the window will act like the window is not there and the click on whatever is behind it...
Thanks!
Philip
Just a thought, couldn't you get the window style (with GetWindowLongPtr), store it as a member variable in you class and then use this as the style to reset in SetWindowLongPtr?
Following is uncheck code (this is assuming you are using C++),
MainWnd::OnFullScreen(...)
{
m_oldStyle = GetWindowLongPtr(GWL_EXSTYLE, m_hwd);
/*
what ever other code is necessary
*/
}
MainWnd::OnExitFullScreen(...)
{
SetWindowLongPtr(m_hwn, GWL_EXSTYLE, m_oldStyle);
/*
and other code as needed
*/
}
I've made two assumptions here:
(1) that you will have two variables, one to contain the old style (m_oldStyle) and one to hold the handle to the window (m_hwd). Note if you are doing strict SDK style coding then the handle will be passed to you as part of WndProc. If you are using MFC there should be member function in the class you derived you main window from. In other cases you are on your own.
(2) the second assumption is that SetWindowLongPtr is called prior to any change of screen type. I believe that SetWindowLongPtr is called during window construction, but it has been several years since I've done serious windows programming using Microsoft frameworks (now I tend to used QT's framework).
I have code where I populate combo box models by text but first time I see strange behavior.
I use Blade GUI editir to create *.ui file where i generate single empty combobox.
After, I fetch combo from methods and modify/fill my combo.
This is my snippets of code:
GtkWidget *combo_screen_share;
GtkTreeModel *model;
// here I get empty combobox
combo_screen_share=myprog_gtk_get_widget(call_view,"window_screen_stream");
GtkCellRenderer *renderer=gtk_cell_renderer_text_new();
model=GTK_TREE_MODEL((store=gtk_list_store_new(1,G_TYPE_STRING)));
int i;
for(i=0; i<200; i++){
gtk_list_store_append(store,&iter);
gtk_list_store_set(store,&iter,0,"Full Screen",-1);
}
gtk_combo_box_set_model(GTK_COMBO_BOX(combo_screen_share),model);
g_object_unref(G_OBJECT(model));
gtk_cell_layout_pack_start(GTK_CELL_LAYOUT(combo_screen_share),renderer,FALSE);
gtk_cell_layout_set_attributes(GTK_CELL_LAYOUT(combo_screen_share),renderer,"text",0,NULL);
gtk_combo_box_set_active(GTK_COMBO_BOX(combo_screen_share),0);
// bind 'onChange' with other method as callback
g_signal_connect(G_OBJECT(combo_screen_share),"changed",(GCallback)gtk_combo_box_new_with_model,NULL);
It should create 200 rows of "Full Screen" string.
However when I click on combobox, I get empty half screen as gap/space and only after all my 200 items.
If I run the loop for 100, space is going to be smaller.
Did someone meet the same thing and know how to fix it?
Thank you,
What you're seeing isn't a "bug" exactly, it's just the way Gtk does combo boxes and you'll have to live with it.
Try another app if you don't believe me --
Open a Gtk app (I used The Gimp)
Find a combo box with several options
Drag the window so that the combo box is near the bottom of the screen
Click on it
When the combo box appears it will have a big empty space at the top, just like yours.
I don't believe there's a fix without patching Gtk itself. For more discussion/rants on this issue see this Launchpad bug and this Gnome Buzilla bug.
I have a WIN32 application. Its main window is hwndMain, one of its child is hwndView. There is one tab control hwndTab on hwndView.
When I resize hwndMain, hwndView is resized and so is hwndTab. It flicker a little, but not much.
I have tried to use WS_EX_COMPOSITED style ( for hwndView or hwndTab), but it just gave me blank window. I tried to use WS_EX_TRANSPARENT and it solves flicker, but when the windows is resized to be larger, the childs are updated very slow, e.g I see black region for one second, then the region is updated.
I have successfully sloved the flicker issue for TreeView by using WS_CHIPCHILDREN style. (See remark below). But using WS_CHIPCHILDREN stlye for hwndView doesn't fix the flicker issue for tab control.
I have paid attention to WM_ERASEBKGND and Not set hbrBackground also.
I want to use double buffer for tab control, but I can't find a tutorial for this purpose. All the tutorial I found is: In WM_PAINT, after creating CompatibleDC and CompatibleBitmap, draw what you want in memdc and.....; But I don't want to do any custom drawing in WM_PAINT for hwndTab. I just want to leave the tab control do this job, but shows the final result only.
Could someone show me a small example how to double buffer a tab control (if you think this will fix the flicker issue of tab control), in the language c + winapi, since I don't have the knowledge of C#, Net,..etc.
Remark: For my TreeView, it is a child of a window hwndContainer. It is created as:
win->hwndContainer = CreateWindowEx(
WS_CLIPCHILDREN,
_T("SUMATRA_PDF_TOCBOX"), NULL,
WS_CHILD,
0, 0, gGlobalPrefs.sidebarDx, 0,
win->hwndPanel, NULL,
ghinst, NULL);
Using WS_CLIPCHILDREN fix the flicker, even if I don't use double buffer. But it is strange to put
WS_CLIPCHILDREN in the first parameter position. If I put it after WS_CHILD, i.e
win->hwndContainer = CreateWindowEx(
NULL,
_T("SUMATRA_PDF_TOCBOX"), NULL,
WS_CHILD | WS_CLIPCHILDREN,
0, 0, gGlobalPrefs.sidebarDx, 0,
win->hwndPanel, NULL,
ghinst, NULL);
,then the flicker still occurs.
So I also tried to use the first way when I created hwndView, but it just gave blank white window.
I am really confused with these stuff.
Here is the blank window picture when I used WS_EX_COMPOSITED for hwndView.
There is no such problem when I used it for hwndContainer.
hwndView in fact has two child: a Tab Control hwndTab and a child which has its own double buffer and drawing. I am not sure if this cause the problem for using WS_EX_COMPOSITED.
You are using the WS_EX_COMPOSITED style. When you pass WS_CLIPCHIDREN as the first argument to the CreateWindowEx, it's interpreting the value of WS_CLIPCHILDREN as an extended window style. Since the value of WS_CLIPCHILDREN is 0x02000000L, the same as WS_EX_COMPOSITED, you've just created a composited window.
And a composited window, according to the documentation, has all of its descendants painted in a bottom-to-top painting order using double-buffering.
I'm not sure what you mean when you say:
I have tried to use WS_EX_COMPOSITED style ( for hwndView or hwndTab), but it just gave me blank window.
You'll have to post code the reproduces this problem. But your second-to-last code snippet is producing a composited window.
I want to use cairo to enhance gtkentry look. For this, I have connected a callback to 'expose-event'. In callback, I call gtkentry's original expose-event handler. After that, I create cairo context and draw some lines and destroy the cairo. I return 'TRUE' as return value of callback function so that expose-event does not propagate.
Now my problem is, I am drawing line from (0,0) to (100,100). But line appears only over the border areas of the gtkentry. The place where text is, it does not appear.
Please help.
Kind Regards
-Durgesh O Mishra
GtkEntry uses an additional GdkWindow for the text area. It is sort-of-private, but you could access it using the following code:
GDK_WINDOW (gdk_window_peek_children (GTK_WIDGET (entry)->window)->data);
So, you can pass this window to gdk_cairo_create().
If you have problems applying this to your code, paste the code — it's hard to guess what to do without having any way to test.