WIN32: Spawning a command-line process
Hi, I am writing a GUI application which executes a command-line executable and reads its output from stdout. For this I am using function g_spawn_async_with_pipes. If command-line program is linked with -mswindows then everything works fine, but I can not execute prog in command line. Stdout is lost. So -mswindows is not an option. Does anybody have an idea how to solve this problem? Thanks. Tomas Soltys ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: WIN32: Spawning a command-line process
Resending with a slight rewording to get this message intact into the
gtk-app-devel-list archive. The archive software at mail.gnome.org has
the From bug!...
If command-line program is linked with -mswindows
You mean -mwindows (just a typo, I am sure, but in case somebody else
doesn't know).
then everything works fine,
You mean everything works as expected when your main (GUI) app runs
the other program and reads its output? Good, that is as expected.
but I can not execute prog in command line.
You mean you can't run the command-line program interactively from a
cmd.exe (or whatever shell) window? True, that's how programs marked
as GUI executables work. You have to explicitly redirect its output
to a file, or a pipe, to see it. Run for instance:
prog | more
or if you are using a Unix-style environment:
prog | less
If you don't want to do that, your simplest option is to just build
two separate versions of the prog program: One linked with
-mwindows, one without. Note that you don't have to change a single
line of code to make it into a GUI application, just link it with
-mwindows.
If you read somewhere how GUI applications should have WinMain() and
not main(), etc, take that with a large pinch of salt. That is just a
*convention* normally in use (enforced?) in Visual Studio, and just
partly, as far as I can recall, supported by mingw.
Looking at it from Windows's POV, the GUI-ness or console-ness of an
.exe is just a single field in the .exe header. One can even change it
in an existing .exe file. I only know of the editbin.exe tool that
comes with MSVC to do that, but as what needs to be done is just to
change one byte, it wouldn't be hard to write a dozen-line program to
do it.
Especially also note that the GUI vs. console field in the .exe
header doesn't have any effect on whether the application can have a
GUI or not.
It's perfectly possible to use editbin to change the executable of,
for instance, Notepad, into a console executable. It will work as
before, but just open a console window (to which it won't print
anything). Note that you have to copy notepad.exe from its normal
location first so that Windows's automatic security mechanism won't
restore it to its original state thinking some tampering is going on.
Does anybody have an idea how to solve this problem?
If you don't want to build two otherwise identical copies of the
prog program (the only difference being that one is linked with
-mwindows and the other one not), one trick could be to use the new
AttachConsole() API that is present in Windows XP and later. Compile
this sample program and check how it works when run from a shell in a
console, or from Explorer. Borrow ideas from this:
#include stdio.h
#define _WIN32_WINNT 0x0500
#include windows.h
int
main (int argc, char **argv)
{
int allocated_new_console = FALSE;
if (!AttachConsole (ATTACH_PARENT_PROCESS))
{
if (!AllocConsole ())
{
MessageBox (NULL,
Could not either attach to parent's console or
allocate a new console.,
Error,
MB_ICONEXCLAMATION|MB_OK);
exit (1);
}
allocated_new_console = TRUE;
}
freopen (CONOUT$, w, stdout);
if (allocated_new_console)
printf (Could not attach to parent's console, had to allocate a
new one, sorry.\n);
printf (Hello there!\n);
Sleep (1);
return 0;
}
In your case you would not have the branch where AllocConsole() is
called. Just try AttachConsole(ATTACH_PARENT_PROCESS) and if that
works, reopen stdout to the console that the process now has. Should
work like a dream.
--tml
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: WIN32: Spawning a command-line process
Compile this sample program Compile it with -mwindows , I forgot to say. It doesn't do anything interesting if built as a console .exe, in fact gives a misleading error message... --tml ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: WIN32: Spawning a command-line process
2009/1/27 Tor Lillqvist t...@iki.fi: If you don't want to do that, your simplest option is to just build two separate versions of the prog program: One linked with -mwindows, one without. Note that you don't have to change a single line of code to make it into a GUI application, just link it with -mwindows. Another common solution is to make the main .exe a GUI, then have a separate tiny non-GUI wrapper program that runs the main GUI, captures the output, and connects to stdin/stdout. In my project I have nip2.exe, my main GUI app, then nip2-cli.exe, a command-line program that runs nip2.exe and redirects. Here's the source: http://vips.svn.sourceforge.net/viewvc/vips/nip2/trunk/src/nip2-cli.c?view=markup It could probably use one of the g_spawn_*() functions and save some space, but it's adapted from another non-glib project. John ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: WIN32: Spawning a command-line process
Let me add also that before you do any of that AttachConsole() and
freopen() magic, you should of course make sure that stdout actually
is attached to an invalid file handle. (stdout normally is attached to
an invalid file handle in a GUI.exe that has been started without
redirecting its stdout. Redirection can either be interactive on the
shell command line, or programmatical, for instance through
g_spawn_async_with_pipes().)
I.e., the logic goes something like this:
if (_get_osfhandle (fileno (stdout)) != -1)
printf (Stdout is fine, apparently you have redirected to a file
or pipe.\n);
else
{
int allocated_new_console = FALSE;
if (!AttachConsole (ATTACH_PARENT_PROCESS))
{
if (!AllocConsole ())
{
MessageBox (NULL,
Could not either attach to parent's console
or allocate a new console.,
Error,
MB_ICONEXCLAMATION|MB_OK);
exit (1);
}
allocated_new_console = TRUE;
}
freopen (CONOUT$, w, stdout);
if (allocated_new_console)
printf (Could not attach to parent's console, had to allocate
a new one, sorry.\n);
}
--tml
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GtkImage
Hello, I was created a space for image on glade-3, and I'm trying to link some imagem to this space. GtkWidget space; space = gtk_image_new_from_file(image.bmp); only this? the image will rezise itself to the space dimensions? ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtk_window_set_skip_taskbar_hint doesn't works on Windows
Thanks Tadej,
Also, is there any ETA to get this fixed? or is there any workaround?
I Tried the code below (among other values for GWL_STYLE), but that is
not exactly that I'm looking for:
handle = (HWND)gdk_win32_drawable_get_handle(window-window);
ShowWindow(handle, SW_HIDE);
SetWindowLong(handle, GWL_EXSTYLE, GetWindowLong(handle,
GWL_EXSTYLE) ~WS_EX_APPWINDOW);
ShowWindow(handle, SW_SHOW);
Thanks in advance
Rodrigo
On Thu, Dec 25, 2008 at 2:38 PM, Tadej Borovšak tadeb...@gmail.com wrote:
Hello.
This is know bug on Windows platform:
http://bugzilla.gnome.org/show_bug.cgi?id=537183
2008/12/25 Rodrigo Miguel rodrm...@gmail.com:
Hi All,
I notice the gtk_window_set_skip_taskbar_hint, doesn't work on windows
since 2.12.9, but it works ok in linux xubuntu 8.04.1 (2.12.9). Also
I've tested on windows with gtk 2.14.6 and I notice the same behavior:
int main(int argc, char *argv[] )
{
GtkWidget *window;
GtkWidget *button;
gtk_init (argc, argv);
window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
gtk_widget_set_size_request(GTK_WIDGET(window), 200, 100);
gtk_window_set_skip_taskbar_hint(GTK_WINDOW(window), TRUE);
g_signal_connect (G_OBJECT (window), destroy, G_CALLBACK
(gtk_main_quit), NULL);
g_signal_connect_swapped (G_OBJECT (window), delete_event,
G_CALLBACK (gtk_widget_destroy), G_OBJECT (window));
button = gtk_button_new_from_stock (GTK_STOCK_PRINT);
g_signal_connect(G_OBJECT(button), clicked,
G_CALLBACK(gtk_main_quit), NULL);
gtk_container_add(GTK_CONTAINER (window),button);
gtk_widget_show(button);
gtk_widget_show(window);
gtk_main();
return 0;
}
Thanks advance
Rodrigo
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
--
Tadej Borovšak
00386 (0)40 613 131
tadeb...@gmail.com
tadej.borov...@gmail.com
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
An 'oldie' question... GtkCList anyone?
Hello people. In the process of converting an old program from mSQL to MySQL, I found a couple of potential traps and optimized a couple of functions. I now have a problem with adding lines into a GtkCList using gtk_clist_append. The code is like this: char *bff, str[4]; bff = strdup(abc|def|ghi|etc); Just to show bff has to freed later splitline(bff, str);This puts pointers into str to each of the substrings (at the start and after each |, converting them to \0 ) gtk_clist_append(clist, str); Add the line, g_free(bff); It looks as if the g_free happens before the append, because gibberish appears on the screen. Is there a way to assure the append is finished before the g_free? John ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: An 'oldie' question... GtkCList anyone?
Hi, try to declare str as: char *str[4]; Regards, Tomas Hello people. In the process of converting an old program from mSQL to MySQL, I found a couple of potential traps and optimized a couple of functions. I now have a problem with adding lines into a GtkCList using gtk_clist_append. The code is like this: char *bff, str[4]; bff = strdup(abc|def|ghi|etc); Just to show bff has to freed later splitline(bff, str); This puts pointers into str to each of the substrings (at the start and after each |, converting them to \0 ) gtk_clist_append(clist, str); Add the line, g_free(bff); It looks as if the g_free happens before the append, because gibberish appears on the screen. Is there a way to assure the append is finished before the g_free? John ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: An 'oldie' question... GtkCList anyone?
Hi, try to declare str as: char *str[4]; Regards, Tomas Hello people. In the process of converting an old program from mSQL to MySQL, I found a couple of potential traps and optimized a couple of functions. I now have a problem with adding lines into a GtkCList using gtk_clist_append. The code is like this: char *bff, str[4]; bff = strdup(abc|def|ghi|etc); Just to show bff has to freed later splitline(bff, str); This puts pointers into str to each of the substrings (at the start and after each |, converting them to \0 ) gtk_clist_append(clist, str); Add the line, g_free(bff); It looks as if the g_free happens before the append, because gibberish appears on the screen. Is there a way to assure the append is finished before the g_free? John ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Full Screen mode behaves differently on two identical systems
Hey All, I have 2 computers, both running Ubuntu 8.10 (kernel2.6.27-9-generic). When my gtkmm application goes to full screen mode, and the user brings up any modal dialog (which is a child of the application main window), on one system everything looks fine. On the other, I get the System menu (Applications Places System) appearing instead of the application menu. When the dialog closes, the Application menu comes back. This is somewhat disconcerting to my users *grin*. Clearly, the systems are different somehow, but I'm at a loss as to exactly where and why it would make a difference. I have multiple examples of each behavior. So far, it seems that older PCs and newer netbooks have the bad behavior, while my development laptops and some newer desktop PCs work flawlessly. The same bad/good behavior happened when all my machines were running Ubuntu 8.04 with multiple kernels. Any ideas? Thanks in advance. -- Garth Upshaw Garth's KidStuff ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: An 'oldie' question... GtkCList anyone?
On Tue, 27 Jan 2009 15:53:03 +0100 (CET) Tomas Soltys tomas.sol...@range-software.com wrote: Hi, try to declare str as: char *str[4]; Thanks for the suggestion, but it _was_ defined as a *str[4], of course. I probably would've experienced a lot of SEGFAULTS if not. Sorry for the typo. John ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: An 'oldie' question... GtkCList anyone?
On Tue, 27 Jan 2009 12:38:09 -0200 John Coppens j...@jcoppens.com wrote: char *bff, str[4]; bff = strdup(abc|def|ghi|etc); Just to show bff has to freed later splitline(bff, str); This puts pointers into str to each of the substrings (at the start and after each |, converting them to \0 ) gtk_clist_append(clist, str); Add the line, g_free(bff); Hi John, first of all I warmly suggest you to update your code to GtkTreeView. GtkCList is not maintained since ages: you'll surely meet bigger problem than this and you'll be alone. Anyway, apart from the typo, I suspect the str array should be NULL terminated because there's no other way gtk_clist_append() can know how many line to append. Ciao -- Nicola ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkImage
If you use glade, then after loading the interface, the widget has already been created for you. There is therefore no need to generate another image widget through a call to gtk_image_new_from_file() and you should use gtk_image_set_from_file instead: GtkWidget *image = ...*get widget pointer from libglade* ...(); gtk_image_set_from_file(image, image.bmp) How to get the widget pointer from libglade is left as an exercise for the reader. (A bad excuse for saying that I am too lazy to look it up. :-) Regards, Dov 2009/1/27 frederico schardong frede@gmail.com Hello, I was created a space for image on glade-3, and I'm trying to link some imagem to this space. GtkWidget space; space = gtk_image_new_from_file(image.bmp); only this? the image will rezise itself to the space dimensions? ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Full Screen mode behaves differently on two identical systems
I have 2 computers, both running Ubuntu 8.10 (kernel2.6.27-9-generic). When my gtkmm application goes to full screen mode, and the user brings up any modal dialog (which is a child of the application main window), on one system everything looks fine. On the other, I get the System menu (Applications Places System) appearing instead of the application menu. When the dialog closes, the Application menu comes back. This is somewhat disconcerting to my users *grin*. Clearly, the systems are different somehow, but I'm at a loss as to exactly where and why it would make a difference. I have multiple examples of each behavior. So far, it seems that older PCs and newer netbooks have the bad behavior, while my development laptops and some newer desktop PCs work flawlessly. The same bad/good behavior happened when all my machines were running Ubuntu 8.04 with multiple kernels. Any ideas? Are you moving executables or recompiling from machine to machine? Are the compiler versions the same across the machines? -- Marshall Lake -- ml...@mlake.net -- http://mlake.net ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Full Screen mode behaves differently on two identical systems
I have found myself some weird behaviour with fullscreen mode and modal windows in Gnome. I would suggest: 1) try a decent window manager, such as Enlightenment. This solved my issues. Of course this is not a good solution, but at least tells you where the problem is. 2) I guess you are using Gtk dialog widgets for your child dialogs. Try replacing one by a Gtk window widget, just to see if you get the same behavior. Using window widgets gives you 5 min more of work but in compensation you get a lot more control over your dialog. Cheers, Carlos On Tue, Jan 27, 2009 at 9:20 AM, Marshall Lake ml...@mlake.net wrote: I have 2 computers, both running Ubuntu 8.10 (kernel2.6.27-9-generic). When my gtkmm application goes to full screen mode, and the user brings up any modal dialog (which is a child of the application main window), on one system everything looks fine. On the other, I get the System menu (Applications Places System) appearing instead of the application menu. When the dialog closes, the Application menu comes back. This is somewhat disconcerting to my users *grin*. Clearly, the systems are different somehow, but I'm at a loss as to exactly where and why it would make a difference. I have multiple examples of each behavior. So far, it seems that older PCs and newer netbooks have the bad behavior, while my development laptops and some newer desktop PCs work flawlessly. The same bad/good behavior happened when all my machines were running Ubuntu 8.04 with multiple kernels. Any ideas? Are you moving executables or recompiling from machine to machine? Are the compiler versions the same across the machines? -- Marshall Lake -- ml...@mlake.net -- http://mlake.net Both. I've tried building on the good machine and moving to the bad as well as building on the bad. In either case, the bad machines exhibit the bad behavior. And yes, the compiler versions are the same. I can really take 2 machines, install Ubuntu 8.10 on each, get all the build-essentials etc. that I need, and build up 2 executables that work differently on each machine. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: An 'oldie' question... GtkCList anyone?
On Tue, 27 Jan 2009 17:02:32 +0100 Nicola Fontana n...@entidi.it wrote: first of all I warmly suggest you to update your code to GtkTreeView. GtkCList is not maintained since ages: you'll surely meet bigger problem than this and you'll be alone. Yes - I'm planning on doing that. But the application has _lots_ of CLists. In fact, I've been think about emulating CLists with GtkTreeView so I can get on without changing the program. Has anyone done that - at least a subset of the CList functions? Anyway, apart from the typo, I suspect the str array should be NULL terminated because there's no other way gtk_clist_append() can know how many line to append. gtk_clist_append appends only 1 row, so that shouldn't be the problem. The elements in the str[] array correspond to cells, the number is defined in the CList, at creation time (gtk_clist_new takes nr of columns as parameter). Number of columns in a CList cannot be changed dynamically. John ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: An 'oldie' question... GtkCList anyone?
I have changed recently my CList widgets to TreeView. I suggest you implement a small test case, learn everything you need to your own purposes, and then (and only then) replace everything. I am almost in the end of replacing 119 option menus to combo boxes, so I understand how you feel... Carlos first of all I warmly suggest you to update your code to GtkTreeView. Yes - I'm planning on doing that. But the application has _lots_ of CLists. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: An 'oldie' question... GtkCList anyone?
On Tue, 27 Jan 2009 19:08:30 -0200
John Coppens j...@jcoppens.com wrote:
On Tue, 27 Jan 2009 17:02:32 +0100
Nicola Fontana n...@entidi.it wrote:
gtk_clist_append appends only 1 row, so that shouldn't be the problem. The
elements in the str[] array correspond to cells, the number is defined in
the CList, at creation time (gtk_clist_new takes nr of columns as
parameter). Number of columns in a CList cannot be changed dynamically.
Yes, I've seen. Anyway, just to be sure, I executed the following
program and works as expected (gtk+-2.14.5) although I had to set
the titles to see all the columns.
#include gtk/gtk.h
int
main(gint argc, gchar **argv)
{
GtkWidget *window;
GtkWidget *clist;
gchar *values[] = {abc, def, ghi, jkl};
gtk_init(argc, argv);
window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
g_signal_connect(window, delete-event,
G_CALLBACK(gtk_main_quit), NULL);
clist = gtk_clist_new_with_titles(4, values);
gtk_container_add(GTK_CONTAINER(window), clist);
gtk_clist_append(GTK_CLIST(clist), values);
gtk_clist_append(GTK_CLIST(clist), values);
gtk_clist_append(GTK_CLIST(clist), values);
gtk_widget_show_all(window);
gtk_main();
return 0;
}
gtk_clist_append() dups the strings, so you can do whatever you
want with values after the call.
If you're lucky there's something wrong in your splitline(),
if not you're experiencing the result of a previous memory
corruption or hitting a GtkCList bug or... who knows.
Ciao
--
Nicola
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: [Patch] Cursor cache
Hi, Am Montag, den 19.01.2009, 03:08 -0500 schrieb Matthias Clasen: On Sun, Jan 18, 2009 at 12:24 PM, Dr. David Alan Gilbert gilbe...@treblig.org wrote: * Matthias Clasen (matthias.cla...@gmail.com) wrote: On Sat, Jan 17, 2009 at 8:19 PM, Dr. David Alan Gilbert gilbe...@treblig.org wrote: * Matthias Clasen (matthias.cla...@gmail.com) wrote: Also, before GDK_BLANK_CURSOR can be used I guess the none-x11 versions have to be fixed up as well - I'll need a hand with that since I just have Linux. Yes, we usually rely on the backend fairies to fill in gaps like that (Hi Tor!). But it would still be good to have a testcase in gdk, so backend maintainers will get a failed test result when they run make check. Regards, Sven PS: I can also try to come up with a patch for adding a test case once this is committed. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [Patch] Cursor cache
On Tue, Jan 27, 2009 at 9:18 AM, Sven Herzberg herzi...@gnome-de.org wrote: PS: I can also try to come up with a patch for adding a test case once this is committed. Awaiting your patch then :-) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
