gtkada problem

gtkada problem

[Evangelista Sami]

Hello everybody

i have a small problem with gtkada:
in the application i am implementing, a long calculus sometimes occur.
during this one, i want to put some informations in the status bar to
inform user.
but theses messages appear only after the calculus is done. so is
there a way to force the drawing of theses messages?
my code looks like this :
-----------------------------------------------
Pop(Win.Status_Bar_Bar, 1);
Mid := Push(Win.Status_Bar_Bar, 1, "Translating");
Translate;
Pop(Win.Status_Bar_Bar, 1);
Mid := Push(Win.Status_Bar_Bar, 1, "Analyzing");
Analyze;
Pop(Win.Status_Bar_Bar, 1);
Mid := Push(Win.Status_Bar_Bar, 1, "Finalizing");
Finalize;
-----------------------------------------------
the "Translating" and "Analyzing" messages never appear on the status
bar

am i clear?

thanks for any response

Sami Evangelista
evangeli@cnam.fr

Re: gtkada problem

[Stephen Leake]

evangeli@cnam.fr (Evangelista Sami) writes:

> Hello everybody
> 
> i have a small problem with gtkada:

You'll get better help on the GtkAda mailing list:
http://lists.act-europe.fr/mailman/listinfo/gtkada

> in the application i am implementing, a long calculus sometimes occur.
> during this one, i want to put some informations in the status bar to
> inform user.
> but theses messages appear only after the calculus is done. so is
> there a way to force the drawing of theses messages?

I'm sure there is, but I don't know what it is :).

-- 
-- Stephe

GtkAda Problem

[Oliver Doerler]

Hi!

Problem with GtkAda in Gtk.Main...

Def. from http://libre.act-europe.fr/GtkAda/docs/gtkada_rm_102.html#SEC444
---------------------------------
type Idle_Callback is access function return Boolean;

function Timeout_Add
   (Interval       : in     Guint32;
   Func            :        Timeout_Callback)
return Timeout_Handler_Id;
---------------------------------

My Code:
---------------------------------
function fidle return boolean is
begin
   Gtk.Fixed.Move (Container, Lkw, 40, 40);

   return true;
end fidle;

fidle_id := Gtk.Main.Idle_Add (fidle'access);
----------------------------------

gnatmake Message:
=>subprogram must not be deeper than access type



I can't see my misstake... help?! :)

Thanks!
Oliver Doerler

Re: GtkAda Problem

[Björn Persson]

Oliver Doerler wrote:

> fidle_id := Gtk.Main.Idle_Add (fidle'access);
> 
> gnatmake Message:
> =>subprogram must not be deeper than access type

Did you declare fidle inside the main subprogram? Move it to a package. 
Idle_Callback is defined on what is called the library level. It's not 
allowed to point to something on a deeper level, and what's inside a 
subprogram is deeper. The rule is there to prevent pointers from 
pointing to something that can go out of scope and disappear before the 
pointer goes out of scope.

I think most beginners try to do this and get confused. I know I did.

-- 
Björn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu

Re: GtkAda Problem

[Nick Roberts]

On Sat, 17 Jul 2004 17:38:05 GMT, Bj�rn Persson <spam-away@nowhere.nil>  
wrote:

> Oliver Doerler wrote:
>
>> fidle_id := Gtk.Main.Idle_Add (fidle'access);
>>  gnatmake Message:
>> =>subprogram must not be deeper than access type
>
> Did you declare fidle inside the main subprogram? Move it to a package.  
> Idle_Callback is defined on what is called the library level. It's not  
> allowed to point to something on a deeper level, and what's inside a  
> subprogram is deeper. The rule is there to prevent pointers from  
> pointing to something that can go out of scope and disappear before the  
> pointer goes out of scope.
>
> I think most beginners try to do this and get confused. I know I did.

If it is possible to move fidle to a library-level package, fine. But
if it would be impractical to do so, I suspect using Unchecked_Access
is the best bet.

-- 
Nick Roberts

Re: GtkAda Problem

[Jeffrey Carter]

Nick Roberts wrote:

> If it is possible to move fidle to a library-level package, fine. But
> if it would be impractical to do so, I suspect using Unchecked_Access
> is the best bet.

'Unchecked_Access is not defined for subprograms.

-- 
Jeff Carter
"Nobody expects the Spanish Inquisition!"
Monty Python's Flying Circus
22

Re: GtkAda Problem

[Nick Roberts]

On Sat, 17 Jul 2004 22:40:16 GMT, Jeffrey Carter <spam@spam.com> wrote:

> Nick Roberts wrote:
>
>> If it is possible to move fidle to a library-level package, fine. But
>> if it would be impractical to do so, I suspect using Unchecked_Access
>> is the best bet.
>
> 'Unchecked_Access is not defined for subprograms.

Silly me. You're right. The weird thing is that I've used Unchecked_Access  
with GNAT (interfacing to Windows). I guess GNAT just allows it. Or was it  
Unchecked_Address? My memory is not very good. I'm very sorry for any  
confusion caused.

I think compilers should provide a non-standard mode permitting  
Unchecked_Access for subprograms, since it's obviously needed sometimes;  
this mode would be forbidden for safety-critical software.

-- 
Nick Roberts

Re: GtkAda Problem

[Simon Wright]

"Nick Roberts" <nick.roberts@acm.org> writes:

> On Sat, 17 Jul 2004 22:40:16 GMT, Jeffrey Carter <spam@spam.com> wrote:
> 
> > Nick Roberts wrote:
> >
> >> If it is possible to move fidle to a library-level package, fine. But
> >> if it would be impractical to do so, I suspect using Unchecked_Access
> >> is the best bet.
> >
> > 'Unchecked_Access is not defined for subprograms.
> 
> Silly me. You're right. The weird thing is that I've used
> Unchecked_Access  with GNAT (interfacing to Windows). I guess GNAT
> just allows it. Or was it  Unchecked_Address? My memory is not very
> good. I'm very sorry for any  confusion caused.

Unrestricted_Access

-- 
Simon Wright                               100% Ada, no bugs.

Re: GtkAda Problem

[Nick Roberts]

On 18 Jul 2004 12:29:51 +0100, Simon Wright <simon@pushface.org> wrote:

> Unrestricted_Access

Aha! Thank you, Simon.

It occurs to me that possibly a better approach would be to declare a  
library package which interfaces to some external subsystem (e.g. GTK or  
Win32) as a generic package (even if it has no generic parameters).

This way, the user can instantiate the package at the appropriate level  
(e.g. immediately in the declarative region of the main subprogram), and  
then use 'Access on subprograms at this level to provide values for  
access-to-subprogram types declared in the package (e.g. for callbacks).

It wouldn't be perfect, but it would actually provide a level (sorry ;-)  
of protection against accidentally calling back a subprogram in an inner  
scope that was no longer active, which is what the standard's restrictions  
on 'Access are intended to do.

I'll have a look at my copy of the AARM to see if I can work out whether  
this would work.

I've just discovered that Windows XP is now displaying the task bar 'low'  
(so that half of it disappears). It's not the monitor. Amazing. Microsoft  
seem to have a /genius/ for bugs!

-- 
Nick Roberts

Re: GtkAda Problem

[Warren W. Gay VE3WWG]

Nick Roberts wrote:
> On 18 Jul 2004 12:29:51 +0100, Simon Wright <simon@pushface.org> wrote:
>> Unrestricted_Access
> Aha! Thank you, Simon.
> 
> It occurs to me that possibly a better approach would be to declare a  
> library package which interfaces to some external subsystem (e.g. GTK 
> or  Win32) as a generic package (even if it has no generic parameters).
> 
> This way, the user can instantiate the package at the appropriate level  
> (e.g. immediately in the declarative region of the main subprogram), 
> and  then use 'Access on subprograms at this level to provide values 
> for  access-to-subprogram types declared in the package (e.g. for 
> callbacks).

There is a problem with this: routines in the generic instantiation
do not permit 'Access. I tried this once, and was burned (ouch). I
forget what the rationale behind it was, but I found it extremely
inconvenient! :<

> I'll have a look at my copy of the AARM to see if I can work out 
> whether  this would work.

The problem I had was I wanted to use one of the routines within the
generic package as a callback, but that was forbidden by the compiler
('Access was not allowed - I think I even tried Unrestricted_Access,
though I am less certain about that. I just remember that I didn't
arrive at a solution at the time).

A specific code sample would help in this discussion, but I don't have
one at the moment.

> I've just discovered that Windows XP is now displaying the task bar 
> 'low'  (so that half of it disappears). It's not the monitor. Amazing. 
> Microsoft  seem to have a /genius/ for bugs!

Well, if XP tells me that I have "unused icons" or "new programs were
installed" one more time, I am likely to have a fit.  >8-/

There must be a way to turn those STUPID features off. The unused icons
feature is the stupidest thing I've seen yet.
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: GtkAda Problem

[Ludovic Brenta]

"Warren W. Gay VE3WWG" writes:
>> I've just discovered that Windows XP is now displaying the task bar
>> 'low' (so that half of it disappears). It's not the
>> monitor. Amazing. Microsoft seem to have a /genius/ for bugs!
>
> Well, if XP tells me that I have "unused icons" or "new programs
> were installed" one more time, I am likely to have a fit.  >8-/
>
> There must be a way to turn those STUPID features off. The unused
> icons feature is the stupidest thing I've seen yet.

<plug mode="shameless">
Yes, there is: install Debian :)
</plug>

-- 
Ludovic Brenta.

Re: GtkAda Problem

[Ed Falis]

On Mon, 19 Jul 2004 23:58:08 +0200, Ludovic Brenta  
<ludovic.brenta@insalien.org> wrote:

> <plug mode="shameless">
> Yes, there is: install Debian
> </plug>

My wife likes it a lot after two weeks on it.

- Ed

-- 
"When I was a kid, I wanted to grow up to be a wise man. Somehow, I just  
turned out to be a wise guy".

Re: GtkAda Problem

[Warren W. Gay VE3WWG]

Ludovic Brenta wrote:

> "Warren W. Gay VE3WWG" writes:
>>>I've just discovered that Windows XP is now displaying the task bar
>>>'low' (so that half of it disappears). It's not the
>>>monitor. Amazing. Microsoft seem to have a /genius/ for bugs!
>>
>>Well, if XP tells me that I have "unused icons" or "new programs
>>were installed" one more time, I am likely to have a fit.  >8-/
>>
>>There must be a way to turn those STUPID features off. The unused
>>icons feature is the stupidest thing I've seen yet.
> 
> <plug mode="shameless">
> Yes, there is: install Debian :)
> </plug>

I have Debian installed on one machine, Gentoo on another.
I have several instances of Linux actually, but the family
PC runs XP.

After I posted my response yesterday, I did a google and
was able to find a solution to that annoyance. But I still
maintain it is a useless/stupid default, if not a useless
feature altogether. IMHO it should never have been the
default.
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: GtkAda Problem

[Nick Roberts]

On Mon, 19 Jul 2004 15:55:31 -0400, Warren W. Gay VE3WWG  
<ve3wwg@cogeco.ca> wrote:

> ...
> There is a problem with this: routines in the generic
> instantiation do not permit 'Access. I tried this once, and
> was burned (ouch). I forget what the rationale behind it was,
> but I found it extremely inconvenient! :<

I think the rationale was that a generic unit can be instantiated
at any level, but it was not desired to require, in effect,
checks inside the body of an instantiation. I've always been in
favour of dropping the restrictions on levels (which would
require implementations to put in dynamic checks in various
places). Anyway, as per Randy's reply, Ada 2005 has already got a
solution to the problem (anonymous access-to-subprogram
parameters).

> A specific code sample would help in this discussion, but I
> don't have one at the moment.

Here's some code copied straight out of a test program I wrote,
to try out some interfacing of GNAT to Win32:

~~~

    function Main_Window_Control (
          Window:  in Win32.WinDef.HWND;
          Message: in Win32.UINT;
          Param_1: in Win32.WPARAM;
          Param_2: in Win32.LPARAM) return Win32.LRESULT;

    pragma Convention(StdCall,Main_Window_Control);

    function Main_Window_Control (
          Window:  in Win32.WinDef.HWND;
          Message: in Win32.UINT;
          Param_1: in Win32.WPARAM;
          Param_2: in Win32.LPARAM) return Win32.LRESULT is
    begin
       case Message is
          when Win32.WinUser.WM_CREATE  => Create_Main_Window(Window);
          when Win32.WinUser.WM_PAINT   => Paint_Main_Window(Window);
          when Win32.WinUser.WM_DESTROY => Win32.WinUser.PostQuitMessage(0);
          when Win32.WinUser.WM_SIZE    => Resize_Main_Window( Window,  
Width => LOWORD(Win32.ULONG(Param_2)), Height =>  
HIWORD(Win32.ULONG(Param_2)) );
          when Win32.WinUser.WM_VSCROLL => Scroll_Main_Window( Window, Way  
=> Down,   Action => LOWORD(Win32.ULONG(Param_1)), Value =>  
HIWORD(Win32.ULONG(Param_1)) );
          when Win32.WinUser.WM_HSCROLL => Scroll_Main_Window( Window, Way  
=> Across, Action => LOWORD(Win32.ULONG(Param_1)), Value =>  
HIWORD(Win32.ULONG(Param_1)) );
          when others => return  
Win32.WinUser.DefWindowProc(Window,Message,Param_1,Param_2);
       end case;
       return 0; -- indicates no error
    end Main_Window_Control;


    ------------------------------------------------------------------------
    Main_Window_Class_Descriptor: aliased Win32.WinUser.WNDCLASS := (
       style         => Win32.WinUser.CS_HREDRAW or  
Win32.WinUser.CS_VREDRAW,
       lpfnWndProc   => Main_Window_Control'Access,
       hInstance     => Win32.WinMain.Get_hInstance,
       hIcon         => Win32.WinUser.LoadIcon( C_NULL,  
Win32.LPCSTR(Win32.WinUser.IDI_APPLICATION) ),
       hCursor       => Win32.WinUser.LoadCursor( C_NULL,  
Win32.LPCSTR(Win32.WinUser.IDC_ARROW) ),
       hbrBackground =>  
Win32.WinDef.HBRUSH( Win32.WinGDI.GetStockObject(Win32.WinGDI.WHITE_BRUSH)  
),
       lpszMenuName  => null,
       lpszClassName => Win32.Addr( Win32.CHAR_array'("SysMets3") &  
Win32.NUL ),
       cbClsExtra | cbWndExtra => 0 );

    Main_Window_Class: Win32.WinDef.ATOM;

    procedure Register_Main_Window_Class is
    begin
       Main_Window_Class :=  
Win32.WinUser.RegisterClass(Main_Window_Class_Descriptor'Access);
       if Main_Window_Class = 0 then raise Win32_Error; end if;
    end Register_Main_Window_Class;

~~~

The trick is that this is all defined in a library-level package, so
I can use Main_Window_Control'Access with impunity.

If you're wondering, the program is an Adafication of the 'SYSMETS3'
program of Charles Petzold's classic Programming Windows 95 book.
(And it works perfectly.) You can see how this kind of program can
get gummed up by the glue (which is why I tried to move most of the
glue code into a separate package).

-- 
Nick Roberts

Re: GtkAda Problem

[Randy Brukardt]

"Nick Roberts" <nick.roberts@acm.org> wrote in message
news:opsba3palkp4pfvb@bram-2...
> On Sat, 17 Jul 2004 22:40:16 GMT, Jeffrey Carter <spam@spam.com> wrote:
>
> > Nick Roberts wrote:
> >
> >> If it is possible to move fidle to a library-level package, fine. But
> >> if it would be impractical to do so, I suspect using Unchecked_Access
> >> is the best bet.
> >
> > 'Unchecked_Access is not defined for subprograms.
>
> Silly me. You're right. The weird thing is that I've used Unchecked_Access
> with GNAT (interfacing to Windows). I guess GNAT just allows it. Or was it
> Unchecked_Address? My memory is not very good. I'm very sorry for any
> confusion caused.
>
> I think compilers should provide a non-standard mode permitting
> Unchecked_Access for subprograms, since it's obviously needed sometimes;
> this mode would be forbidden for safety-critical software.

The Amendment provides anonymous access-to-subprogram types for this
purpose. (They can't be mixed with named access-to-subprogram types to avoid
problems). That would be the best way to solve this problem. Of course,
you'd need an Ada 2005 compiler. (Note that the containers library uses
anonymous access-to-subprogram rather than a generic to implement iterators,
so this will show up sooner rather than later in compilers.)

             Randy.

Re: GtkAda Problem

[Nick Roberts]

On Sat, 17 Jul 2004 18:05:38 +0200, Oliver Doerler  
<oliver.doerler@novatek.de> wrote:

> fidle_id := Gtk.Main.Idle_Add (fidle'access);

Probably you need to use Unchecked_Access rather than just the Access  
attribute. You are then responsible for ensuring that fidle will never be  
called after the (I assume) subprogram that contains it has returned.

I don't actually know anything about GtkAda, so someone more knowledgeable  
may have a more definitive answer. HTH.

-- 
Nick Roberts

Re: GtkAda Problem

[Oliver Doerler]

Thanks for your Help! The Problem has been solved! :)

Olli