Re: g_spawn_async_with_pipes and WIN32
[Sorry, my last reply was sent *from* the wrong place. This is a
duplicate...]
On Fri, 2007-06-22 at 18:54 +0300, Tor Lillqvist wrote:
> Alan M. Evans writes:
> > This is being compiled with VC6, and does depend (indirectly) on
> > msvcrt.dll.
>
> OK, good.
>
> Are you saying that my method should work in this circumstance?
>
> In principle, yes. In practice, if it doesn't, file a bug report at
> bugzilla.gnome.org and include a complete but minimal sample program
> source code as an attachment.
I created the minimal sample program, and it works! The working example
is virtually copy/pasted out of the non-working code.
So, the working example looks like this:
int main() {
g_spawn_async_with_pipes();
WaitForSingleObject();
_read();
_close();
}
And the non-working one looks like:
DLL:
__declspec( dllexport ) int func() {
g_spawn_async_with_pipes();
WaitForSingleObject();
_read();
_close();
}
Program:
#include "DLL.h"
int main() {
myfunc();
}
The interesting part of func() in the non-working version looks exactly
like the corresponding part of main in the working version. I've
compared them side-by-side. (They should look the same -- one was
copy/pasted from the other.) Does this scenario provide any hint about
whats going wrong?
This is very frustrating. Stuff like this makes me want to give up on
this programming stuff and go do something easy, like particle physics.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Proper Handling of GtkTreeModelFilters
Yeti, > What holds references to currentModel after the > gtk_tree_view_set_model() call? If it is a filter model, then nothing. If it was the base model then I was maintaining my own global pointer to it. I apologize for the difficult code snippet but regardless you have helped me tremendously. I'll be re-working my framework to align more closely with what you've described. (Makes way more sense.) Thanks so much! Matt ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Proper Handling of GtkTreeModelFilters
On Fri, Jun 22, 2007 at 02:47:30PM -0400, Matthew Yaconis wrote:
> I have an underlying model for a TreeView in my application that I am
> filtering based on certain user selections. I maintain a global reference
> to the "base" TreeModel (which is sometimes attached to the TreeView used to
> display the information.) The mechanism I am using goes something like
> this:
>
> 1. User selects a new filter criteria
> 2. (Depending on the selection) Either a) gtk_tree_model_filter_new to
> create a new filter based on the user's criteria from the global "base"
> model or b) use the base model.
> 3. gtk_tree_view_set_model( [selected model])
GtkTreeModelFilter does not contain much data to preserve.
So, to get a different filter, just take the current
filter and call gtk_tree_model_filter_set_visible_func() or
gtk_tree_model_filter_set_modify_func() on it -- or change
the private data the filter uses and call
gtk_tree_model_filter_refilter().
And instead of switching to the base model you can set the
visible func to one that always returns TRUE (for some
reason it is not possible to set the filter functions back
to NULL). This saves you testing whether to convert iters
and paths or not as you convert them always.
I only physically replace the filter if the virtual root has
to change as it is construction only property. Sometimes
one has a handful of well-defined (semi)fixed filters that
it makes sense to keep around, but usually not.
> I was thinking this is probably leaving a bunch of filtered tree models
> around that aren't doing anything but taking up space...do I need to be
> g_object_unref'ing the old filter models? I attempted a "replace" function
> that looks something like:
>
> void replaceTreeModel(GtkTreeModel *model)
> {
> GtkTreeView *treeview = [get the widget];
> GtkTreeModel *currentModel = gtk_tree_view_get_model(treeview);
>
> gtk_tree_view_set_model( treeview, model );
>
> // The following makes the application unstable and crash in the filter
> function so I've commented it out for now
> //if (GTK_IS_TREE_MODEL_FILTER( currentModel))
> //{
> // g_object_unref( G_OBJECT(currentModel));
> //}
> }
What holds references to currentModel after the
gtk_tree_view_set_model() call? GtkTreeModelFilter is
created with reference count 1, so you should be left with
this inital reference at the end -- but only if you didn't
released it earlier. And if you did, then currentModel is
already destroyed when you try GTK_IS_TREE_MODEL_FILTER().
It's hard to deduce anything from such code fragment.
If you don't need to keep the filters around, it's probably
easiest to release the inital reference immediately after
you do gtk_tree_view_set_model() and do not care about them
any more as they will be destroyed automatically once
nothing needs them.
Yeti
--
http://gwyddion.net/
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Proper Handling of GtkTreeModelFilters
I have an underlying model for a TreeView in my application that I am
filtering based on certain user selections. I maintain a global reference
to the "base" TreeModel (which is sometimes attached to the TreeView used to
display the information.) The mechanism I am using goes something like
this:
1. User selects a new filter criteria
2. (Depending on the selection) Either a) gtk_tree_model_filter_new to
create a new filter based on the user's criteria from the global "base"
model or b) use the base model.
3. gtk_tree_view_set_model( [selected model])
I was thinking this is probably leaving a bunch of filtered tree models
around that aren't doing anything but taking up space...do I need to be
g_object_unref'ing the old filter models? I attempted a "replace" function
that looks something like:
void replaceTreeModel(GtkTreeModel *model)
{
GtkTreeView *treeview = [get the widget];
GtkTreeModel *currentModel = gtk_tree_view_get_model(treeview);
gtk_tree_view_set_model( treeview, model );
// The following makes the application unstable and crash in the filter
function so I've commented it out for now
//if (GTK_IS_TREE_MODEL_FILTER( currentModel))
//{
// g_object_unref( G_OBJECT(currentModel));
//}
}
What is the best/proven way of doing something like this?
Thanks,
Matt
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_spawn_async_with_pipes and WIN32
Alan M. Evans writes: > This is being compiled with VC6, and does depend (indirectly) on > msvcrt.dll. OK, good. Are you saying that my method should work in this circumstance? In principle, yes. In practice, if it doesn't, file a bug report at bugzilla.gnome.org and include a complete but minimal sample program source code as an attachment. --tml ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_spawn_async_with_pipes and WIN32
On Fri, 2007-06-22 at 11:37 +0300, Tor Lillqvist wrote: > Alan M. Evans writes: > > The process being called simply prints a short message and returns. I > > see the message if I execute the program from a command prompt under > > Windows. The linux version works, In the Windows version, _read() always > > returns -1, errno=EBADF. > > Does your code use the same C runtime library as GLib does, > msvcrt.dll, which is part of the operating system? If not, the file > handles returned have no meaning in your code. File handles are > basically indexes into a table in the C library. Microsoft in their > infinite wisdom provides so many C runtimes libraries, and their newer > tools for some reason don't allow building code against msvcrt.dll... > > If you want to use msvcrt.dll, you should either use the older, but > for plain C still perfectly usable, Visual C 6.0. Or use gcc, > i.e. mingw. This is being compiled with VC6, and does depend (indirectly) on msvcrt.dll. Are you saying that my method should work in this circumstance? ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_spawn_async_with_pipes and WIN32
Alan M. Evans writes: > The process being called simply prints a short message and returns. I > see the message if I execute the program from a command prompt under > Windows. The linux version works, In the Windows version, _read() always > returns -1, errno=EBADF. Does your code use the same C runtime library as GLib does, msvcrt.dll, which is part of the operating system? If not, the file handles returned have no meaning in your code. File handles are basically indexes into a table in the C library. Microsoft in their infinite wisdom provides so many C runtimes libraries, and their newer tools for some reason don't allow building code against msvcrt.dll... If you want to use msvcrt.dll, you should either use the older, but for plain C still perfectly usable, Visual C 6.0. Or use gcc, i.e. mingw. --tml ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
