Board index » cppbuilder » Windows API

Windows API


2003-11-27 03:21:16 AM
cppbuilder85
For how long do you think it will still be possible to cling to programming
the Windows API - for exemple encapsulating them in c++ classes. Both
Builder 6.0 and the personal X does it nicely and I sure hate to see it go.
What will be the best future alternative? Changeing between programming the
API and using the VCL has been a treat - sometimes leaner code, sometimes
rapid development. How to prepare for the future if you want to continue to
use c++ (I will start to nibble att Java too)? Greetings hans
 
 

Re:Windows API

Everyone says that win32 is going away right? Well doesn't wxWindows use
win32? It doesn't use .NET for sure. Would it even be possible to compile
wxWindows code on .NET? I guess if the wxWindows could be used with a
managed C++ compiler.
Therefore, my point is, that if the reason Delphi must use dot net is
because Win32 is going away. What is the point of wxWindows?
My personal viewpoint is that win32 native applications will be around for a
long time (>10 years).
-Dave
"Hans Jönsson" < XXXX@XXXXX.COM >wrote in message
Quote
For how long do you think it will still be possible to cling to
programming
the Windows API - for exemple encapsulating them in c++ classes. Both
Builder 6.0 and the personal X does it nicely and I sure hate to see it
go.
What will be the best future alternative? Changeing between programming
the
API and using the VCL has been a treat - sometimes leaner code, sometimes
rapid development. How to prepare for the future if you want to continue
to
use c++ (I will start to nibble att Java too)? Greetings hans


 

Re:Windows API

My guess is that:
- Win32 apps will be just as fast on Longhorn and any other MS OS
rev that comes out for the rest of this decade.
= the main advantage of .NET over VCL for most client apps will be
64 bit address space. But since I don't need multi-gigabyte address
spaces for the apps I write I do not care. I don't that changing in the
foreseeable future.
- MS isn't going to withdraw any Win32 APIs in the next 15 years and
maybe longer.
MS wants us to move to new APIs. That does not mean that it is
necessarily in our best interest to do so.
Hans Jönsson wrote:
Quote
For how long do you think it will still be possible to cling to programming
the Windows API - for exemple encapsulating them in c++ classes. Both
Builder 6.0 and the personal X does it nicely and I sure hate to see it go.
What will be the best future alternative? Changeing between programming the
API and using the VCL has been a treat - sometimes leaner code, sometimes
rapid development. How to prepare for the future if you want to continue to
use c++ (I will start to nibble att Java too)? Greetings hans


 

{smallsort}

Re:Windows API

"Drobins" < XXXX@XXXXX.COM >wrote in message
Quote
Everyone says that win32 is going away right?
It is not going away, Microsoft said as much. But it is being re-written
internally, and will not be the primary API anymore once Longhorn (the next
version of Windows) is released in a couple of years.
Quote
Well doesn't wxWindows use win32?
At the moment. But it is actually a cross-platform library, it just happens
to use Win32 under the Windows platform.
Quote
It doesn't use .NET for sure.
There is a .NET wrapper available for C#, wxnet.sourceforge.net. It
is not even limited to Microsoft's .NET implementation, but also works with
other implementations, namely "Mono" and "DotGNU Portable.NET".
Gambit
 

Re:Windows API

"Randall Parker" < XXXX@XXXXX.COM >wrote in
message news:3fc511d2$ XXXX@XXXXX.COM ...
Quote
- Win32 apps will be just as fast on Longhorn
Doubtful. The Win32 API is being re-written to have a .NET core. The API
will be kept for compatibility reasons only.
Quote
= the main advantage of .NET over VCL for most client
apps will be 64 bit address space.
Also garbage collection, extra security, etc.
Gambit
 

Re:Windows API

I've yet to see an authoritative source for the contention that Win32
APIs will call down into the .NET apis that the .NET apps will call.
That they will both call down to some common lower layer seems far more
likely.
Garbage collection: Basic and Java have had it for a long time. Extra
security: Not that much an issue for most client apps. Most apps do not
have to worry about buffer overflow exploits because most do not play as
servers on the public internet.
Remy Lebeau (TeamB) wrote:
Quote
"Randall Parker" < XXXX@XXXXX.COM >wrote in
message news:3fc511d2$ XXXX@XXXXX.COM ...
>- Win32 apps will be just as fast on Longhorn


Doubtful. The Win32 API is being re-written to have a .NET core. The API
will be kept for compatibility reasons only.


>= the main advantage of .NET over VCL for most client
>apps will be 64 bit address space.


Also garbage collection, extra security, etc.


Gambit


 

Re:Windows API

"Randall Parker" < XXXX@XXXXX.COM >wrote in
message news:3fc54be9$ XXXX@XXXXX.COM ...
Quote
I've yet to see an authoritative source for the contention
that Win32 APIs will call down into the .NET apis that
the .NET apps will call.
At one point, Microsoft released a chart that showed the relationship
between the various APIs available in Longhorn, but I can't find it at the
moment. Navigating Microsoft's site is a pain, but I know I saw the chart
floating around somewhere.
Quote
That they will both call down to some common lower layer
seems far more likely.
Nope, Win32 will call into .NET, which will do all of the work.
Gambit
 

Re:Windows API

On Wed, 26 Nov 2003 18:00:43 -0800, "Remy Lebeau \(TeamB\)"
< XXXX@XXXXX.COM >wrote:
Quote

"Randall Parker" < XXXX@XXXXX.COM >wrote in
message news:3fc54be9$ XXXX@XXXXX.COM ...
>I've yet to see an authoritative source for the contention
>that Win32 APIs will call down into the .NET apis that
>the .NET apps will call.

At one point, Microsoft released a chart that showed the relationship
between the various APIs available in Longhorn, but I can't find it at the
moment. Navigating Microsoft's site is a pain, but I know I saw the chart
floating around somewhere.

>That they will both call down to some common lower layer
>seems far more likely.

Nope, Win32 will call into .NET, which will do all of the work.
If you don't have a source to point to, please stop repeating this. I
believe that in the time between now and Longhorn's release, there
will be more information about the relationship between various system
components. Until more information is available, I believe your
claims are speculative and misleading. Although I suspect my request
will fall on deaf ears, I am begging you to avoid making simplfied
statements with absolute certainty about implementation details in a
system as complicated as Windows/WinFX/.NET/Win32 when we are two
years from the release.
msdn.microsoft.com/Longhorn/understanding/pillars/default.aspx
download.microsoft.com/download/a/2/f/a2fc47d2-8bdf-4977-8364-1f38b893dba5/lharch_pdc2003.png
This is NOT a great diagram as there are missing parts and the
relationships between the pieces are unclear (obviously the emphasis
is on the WinFX functionality).
Chris Hill
XXXX@XXXXX.COM
 

Re:Windows API

"Chris Hill" < XXXX@XXXXX.COM >wrote in message
That is not the diagram I was referring to earlier. There is another one I
have seen which actually shows the hierarchy relationships between the
components, and at what levels they call each other. It was a B&W tree
graph with lines connecting the various levels.
Gambit
 

Re:Windows API

On Thu, 27 Nov 2003 09:17:24 GMT, XXXX@XXXXX.COM (Chris Hill) wrote:
Quote

If you don't have a source to point to, please stop repeating this. I
believe that in the time between now and Longhorn's release, there
will be more information about the relationship between various system
components. Until more information is available, I believe your
claims are speculative and misleading.
I agree with your comments. There are way too many speculative
comments posted as facts in this newsgroup. The only thing I've been
able to find is that MS say Win32 apps will "work as expected" in
Longhorn.
Graeme
 

Re:Windows API

"Graeme Prentice" < XXXX@XXXXX.COM >wrote in message
Quote
I agree with your comments. There are way too many speculative
comments posted as facts in this newsgroup. The only thing I've been
able to find is that MS say Win32 apps will "work as expected" in
Longhorn.
Seconded. The only things we can say for sure are that:
a) Win32 apps will continue to run just fine under Longhorn -- just like
Win16, and DOS stuff which will continue to run just fine too.
b) The Win32 API will not be decimated under Longhorn. The same
labyrinthine mess of API calls we've come to know and love will still be
there. If this were not so, then (a) would not apply.
c) Win32 apps will be just as fast under Longhorn as they are right now.
We can say all this for sure because Microsoft ARE NOT DUMB. Are they
likely to release a new platform where legacy Win32 apps run like a
one-legged dog in treacle? Nope. If they did that, they may as well not
bother.
Dave
 

Re:Windows API

Hello! everybody!
I am studying to draw some region with Windows Api , polygons and rects.
The problem is how can I edit a existed Region? for Example,how to drag a
point or an edge of a region to resize it, just like a resizable control do?
Could anyone can help give some hint or an example?
I'm using D7.
Many thanks!
Miles
 

Re:Windows API

In article < XXXX@XXXXX.COM >, Miles wrote:
Quote
I am studying to draw some region with Windows Api , polygons and rects.
The problem is how can I edit a existed Region? for Example,how to drag a
point or an edge of a region to resize it, just like a resizable control do?
Could anyone can help give some hint or an example?
Well, don't get too fixated on the regions themselves. They are OK for
display, but for your purpose (hittest detection) you need to keep a list of
"objects" (in the generic sense, implementation does not matter for this
discussion) that make up your graphic. Each object would a list of the control
points with coordinates. In your handlers for the mouse events you can now
walk over the list, find the point or edge the mouse is over, and act
accordingly.
To speed up the search process each object should have a BoundsRect property
that defines a rectangle including all elements of the object. That allows you
to quickly determine if the mouse is over the objects area. For overlapping
objects the list sequence would define the Z-order of the objects. Once you
have found the object the mouse is over you need to find the control point
near enough to the mouse. With many points to check it pays to invest some
brain power in a sorting scheme that allows some kind of binary search to be
performed on the points, so you don't need to iterate over all of them. There
should be plenty of literature around on this subject.
Moving a control point basically goes like this:
On a mouse down you determine which point is near enough to the mouse position
to consider it hit. Remember that point (the object it is in, the index of the
point in the object, whatever), set a boolean flag that indicates that a drag
is in progress, perhaps change the mouse cursor as a visual cue, and store the
mouse position.
On a mouse move you first check if you are in a drag operation. If not,
nothing needs to be done (or perhaps you want to highlight things near the
mouse the user might select). If a drag is in progress you determine the
distance the mouse has moved from the last stored position, move the "active"
point the same distance, and tell the object being modified to redraw the part
that has changed, which may also require parts beneath to be redrawn that
belong to other objects.
On a mouse up you clear the drag state flag to indicate that the drag has
finished, and restore the mouse cursor to the default pointer.
Peter Below (TeamB)
Don't be a vampire (slash7.com/pages/vampires),
use the newsgroup archives :
www.tamaracka.com/search.htm
groups.google.com
www.prolix.be
 

Re:Windows API

Peter,
Thank you so much for you instruction so specific. It can be very helpful.
But as for
"..., move the "active" point the same distance, and tell the object being
modified to redraw the part that has changed, which may also require parts
beneath to be redrawn that belong to other objects...."
I doubt if a region can be drawn partially, or shall I draw a new region
every time when mouse is moved ?
Best regards!
Miles
 

Re:Windows API

In article < XXXX@XXXXX.COM >, Miles wrote:
Quote
But as for
"..., move the "active" point the same distance, and tell the object being
modified to redraw the part that has changed, which may also require parts
beneath to be redrawn that belong to other objects...."

I doubt if a region can be drawn partially, or shall I draw a new region
every time when mouse is moved ?
The key is to use clipping regions. Create a clipping region that only
contains the part of the image that changed, select it into the canvas (see
SelectClipRgn). You can now recreate the Window region for the object to
draw and draw it completely, but only the part inside the clipping region
will actually been drawn.
Peter Below (TeamB)
Don't be a vampire (slash7.com/pages/vampires),
use the newsgroup archives :
www.tamaracka.com/search.htm
groups.google.com
www.prolix.be