What is AGL

  • Thread starter Thread starter Thomas
  • Start date Start date
T

Thomas

Hi, guys!

Do you know what is "AGL" on earth? its design or purpose.
Any information about it would be very appreciated!

Thomas
 
AGL is a native graphic layer used by CF as a plumbing between CF Controls
(Form, Label etc) and graphic objects (Graphics, Brush, Font etc) and OS
primitives such as User (Windows, Menus, Controls) and GDI (Display
Contexts, Fonts, Bitmaps) objects.
You are not supposed to use it directly. In VB.NET projects it is visible in
the browser but has no immediate use
 
Hi, Alex

I want to get a detailed introduction about it. Do you know any
information source?

Is this native layer in "System.Windows.Forms.dll"?

What relation is it between AGL and Win32? you know, AGL have wrapped
the windows Handle and this is really beyond me.

Thomas
 
As Alex alluded, it's internal plumbing and it's not documented anywhere.
If you have need to use it, you'll both know it and understand what's in it.
I know, it sounds like a catch-22.

-Chris
 
You know, I also don't want to dig it out. But I have to for this is
really related to my present work.

Does anyone provide me any detailed information about it?

Tom
 
See, what Chris and I are saying is that it is *not documented*. That means
someone has to reverse-engineer it and produce the documentation. The thing
is that nobody really needs it, which makes you a prime candidate to do it.
I'm also curious as of in what line of work you might find it useful

Thomas said:
You know, I also don't want to dig it out. But I have to for this is
really related to my present work.

Does anyone provide me any detailed information about it?

Tom

"Chris Tacke, eMVP" <ctacke[at]Open_NET_CF[dot]org> wrote in message
As Alex alluded, it's internal plumbing and it's not documented anywhere.
If you have need to use it, you'll both know it and understand what's in it.
I know, it sounds like a catch-22.

-Chris



and
OS
 
Hi Alex,

The other thing about APIs that are not documented is that they may be
subject to change without notice. I don't know if that is a real concern in
this situation, but it's something to think about.
--
Ginny Caughey
..Net Compact Framework MVP

Alex Feinman said:
See, what Chris and I are saying is that it is *not documented*. That means
someone has to reverse-engineer it and produce the documentation. The thing
is that nobody really needs it, which makes you a prime candidate to do it.
I'm also curious as of in what line of work you might find it useful

Thomas said:
You know, I also don't want to dig it out. But I have to for this is
really related to my present work.

Does anyone provide me any detailed information about it?

Tom

"Chris Tacke, eMVP" <ctacke[at]Open_NET_CF[dot]org> wrote in message
As Alex alluded, it's internal plumbing and it's not documented anywhere.
If you have need to use it, you'll both know it and understand what's
in
 
My company want to develop some Control on this platform. At present,
System.Windows.Forms.Control in .netcf has not provided enough support
for Control's developing. So trouble is coming. I have to wrap AGL or
Win32 to realize some functions. But in futrue, AGL will be changed,
so I want to know more to avoid some of future hard work.

Alex Feinman said:
See, what Chris and I are saying is that it is *not documented*. That means
someone has to reverse-engineer it and produce the documentation. The thing
is that nobody really needs it, which makes you a prime candidate to do it.
I'm also curious as of in what line of work you might find it useful

Thomas said:
You know, I also don't want to dig it out. But I have to for this is
really related to my present work.

Does anyone provide me any detailed information about it?

Tom

"Chris Tacke, eMVP" <ctacke[at]Open_NET_CF[dot]org> wrote in message
As Alex alluded, it's internal plumbing and it's not documented anywhere.
If you have need to use it, you'll both know it and understand what's in it.
I know, it sounds like a catch-22.

-Chris


Hi, Alex

I want to get a detailed introduction about it. Do you know any
information source?

Is this native layer in "System.Windows.Forms.dll"?

What relation is it between AGL and Win32? you know, AGL have wrapped
the windows Handle and this is really beyond me.

Thomas

"Alex Feinman [MVP]" <[email protected]> wrote in message
AGL is a native graphic layer used by CF as a plumbing between CF Controls
(Form, Label etc) and graphic objects (Graphics, Brush, Font etc)
and
OS
primitives such as User (Windows, Menus, Controls) and GDI (Display
Contexts, Fonts, Bitmaps) objects.
You are not supposed to use it directly. In VB.NET projects it is visible in
the browser but has no immediate use

Hi, guys!

Do you know what is "AGL" on earth? its design or purpose.
Any information about it would be very appreciated!

Thomas
 
But the whole Control object is not extensible. The helper classes are
either private or return values of private types. There is nothing to be
gained by trying to implement your wrapper in the same way AGL is done.
Besides 80% of it are wrappers for either things like
ListView_GetSelectedCount or calls like GDI/User calls, such as GetWindow or
SetWindowText.

If you insist, use ildasm or Anakrino to peek inside
System.Windows.Forms.dll and see for yourself.

Thomas said:
My company want to develop some Control on this platform. At present,
System.Windows.Forms.Control in .netcf has not provided enough support
for Control's developing. So trouble is coming. I have to wrap AGL or
Win32 to realize some functions. But in futrue, AGL will be changed,
so I want to know more to avoid some of future hard work.

"Alex Feinman [MVP]" <[email protected]> wrote in message
See, what Chris and I are saying is that it is *not documented*. That means
someone has to reverse-engineer it and produce the documentation. The thing
is that nobody really needs it, which makes you a prime candidate to do it.
I'm also curious as of in what line of work you might find it useful

Thomas said:
You know, I also don't want to dig it out. But I have to for this is
really related to my present work.

Does anyone provide me any detailed information about it?

Tom

"Chris Tacke, eMVP" <ctacke[at]Open_NET_CF[dot]org> wrote in message
As Alex alluded, it's internal plumbing and it's not documented anywhere.
If you have need to use it, you'll both know it and understand
what's in
it.
I know, it sounds like a catch-22.

-Chris


Hi, Alex

I want to get a detailed introduction about it. Do you know any
information source?

Is this native layer in "System.Windows.Forms.dll"?

What relation is it between AGL and Win32? you know, AGL have wrapped
the windows Handle and this is really beyond me.

Thomas

"Alex Feinman [MVP]" <[email protected]> wrote in
message
AGL is a native graphic layer used by CF as a plumbing between
CF
Controls
(Form, Label etc) and graphic objects (Graphics, Brush, Font
etc)
and
OS
primitives such as User (Windows, Menus, Controls) and GDI (Display
Contexts, Fonts, Bitmaps) objects.
You are not supposed to use it directly. In VB.NET projects it
is
visible in
the browser but has no immediate use

Hi, guys!

Do you know what is "AGL" on earth? its design or purpose.
Any information about it would be very appreciated!

Thomas
 
Or better yet Salamander. But I have to agree with Alex that I think you're
on the wrong path and are destined to waste a lot of time. AGL is a tar pit
you'll have a hard time getting out of. If you want to create custom
controls and need the WinAPI, just P/Invoke the GDI calls directly.

--
Chris Tacke, eMVP
Co-Founder and Advisory Board Member
www.OpenNETCF.org
---
Windows CE Product Manager
Applied Data Systems
www.applieddata.net


Alex Feinman said:
But the whole Control object is not extensible. The helper classes are
either private or return values of private types. There is nothing to be
gained by trying to implement your wrapper in the same way AGL is done.
Besides 80% of it are wrappers for either things like
ListView_GetSelectedCount or calls like GDI/User calls, such as GetWindow or
SetWindowText.

If you insist, use ildasm or Anakrino to peek inside
System.Windows.Forms.dll and see for yourself.

Thomas said:
My company want to develop some Control on this platform. At present,
System.Windows.Forms.Control in .netcf has not provided enough support
for Control's developing. So trouble is coming. I have to wrap AGL or
Win32 to realize some functions. But in futrue, AGL will be changed,
so I want to know more to avoid some of future hard work.

"Alex Feinman [MVP]" <[email protected]> wrote in message
do
it.
I'm also curious as of in what line of work you might find it useful

You know, I also don't want to dig it out. But I have to for this is
really related to my present work.

Does anyone provide me any detailed information about it?

Tom

"Chris Tacke, eMVP" <ctacke[at]Open_NET_CF[dot]org> wrote in message
As Alex alluded, it's internal plumbing and it's not documented
anywhere.
If you have need to use it, you'll both know it and understand what's in
it.
I know, it sounds like a catch-22.

-Chris


Hi, Alex

I want to get a detailed introduction about it. Do you know any
information source?

Is this native layer in "System.Windows.Forms.dll"?

What relation is it between AGL and Win32? you know, AGL have wrapped
the windows Handle and this is really beyond me.

Thomas

AGL is a native graphic layer used by CF as a plumbing between CF
Controls
(Form, Label etc) and graphic objects (Graphics, Brush, Font etc)
and
OS
primitives such as User (Windows, Menus, Controls) and GDI (Display
Contexts, Fonts, Bitmaps) objects.
You are not supposed to use it directly. In VB.NET projects it is
visible in
the browser but has no immediate use

Hi, guys!

Do you know what is "AGL" on earth? its design or purpose.
Any information about it would be very appreciated!

Thomas
 
Yes, I got it. Chris, Alex, Ginny, thank all of you so much! :)

Tom

Chris Tacke said:
Or better yet Salamander. But I have to agree with Alex that I think you're
on the wrong path and are destined to waste a lot of time. AGL is a tar pit
you'll have a hard time getting out of. If you want to create custom
controls and need the WinAPI, just P/Invoke the GDI calls directly.

--
Chris Tacke, eMVP
Co-Founder and Advisory Board Member
www.OpenNETCF.org
---
Windows CE Product Manager
Applied Data Systems
www.applieddata.net


Alex Feinman said:
But the whole Control object is not extensible. The helper classes are
either private or return values of private types. There is nothing to be
gained by trying to implement your wrapper in the same way AGL is done.
Besides 80% of it are wrappers for either things like
ListView_GetSelectedCount or calls like GDI/User calls, such as GetWindow or
SetWindowText.

If you insist, use ildasm or Anakrino to peek inside
System.Windows.Forms.dll and see for yourself.

Thomas said:
My company want to develop some Control on this platform. At present,
System.Windows.Forms.Control in .netcf has not provided enough support
for Control's developing. So trouble is coming. I have to wrap AGL or
Win32 to realize some functions. But in futrue, AGL will be changed,
so I want to know more to avoid some of future hard work.

"Alex Feinman [MVP]" <[email protected]> wrote in message
See, what Chris and I are saying is that it is *not documented*. That means
someone has to reverse-engineer it and produce the documentation. The thing
is that nobody really needs it, which makes you a prime candidate to
do
it.
I'm also curious as of in what line of work you might find it useful

You know, I also don't want to dig it out. But I have to for this is
really related to my present work.

Does anyone provide me any detailed information about it?

Tom

"Chris Tacke, eMVP" <ctacke[at]Open_NET_CF[dot]org> wrote in message
As Alex alluded, it's internal plumbing and it's not documented anywhere.
If you have need to use it, you'll both know it and understand
what's in
it.
message
CF
Controls
is
visible in
 
There is no documentation nor detailed information outside of Microsoft. It
is for the internal use of the framework only and subject to change at the
whim of the developers at Microsoft. Find a different approach or figure it
out through experimentation and hope they don't change anything you need for
your product to go into production.
 
Back
Top