TApplication OnIdle/MessageLoop
Günter Neiß
unfortunaly Borland encapsulated some of the MessageLoop in TApplication. I
do some investigation what happens in TApplication and find out (remark I am
using BCB3.0):
The messageLoop is implemented as follows:
TApplication::Run:
do ( HandleMessage() ) while( !Terminated );
TApplication::HandleMessage:
if( !ProcessMessage ) Idle();
TApplication::ProcessMessage:
while( 'there is any message present' )
'ProcessThisMessage';
TApplication::Idle:
bool Done = true;
if( FOnIdle ) FOnIdle( this, Done );
if( Done ) WaitMessage();
My problem with this is that they use 'WaitMessage' instead of
'MsgWaitForMultipleObjectsEx'.
- This means that I can't handle Event's when the app is waiting for
messages.
- APC's are not called when waiting for Messages.
OK, I can set my own func to Application->OnIdle.
This function in turn will call 'MsgWaitForMultipleObjectsEx' and handle
Event's and/or APC's.
The disadvantage of this is, that I can't do that in a compatible way inside
a component.
IMHO TApplication should be expanded in the following way:
- OnIdle isn't just a pointer, it is a list of functions that should be
called on Idle. This means You have to use
Application->OnIdle->Add( MyOnIdleFunc );
and
Application->OnIdle->Remove( MyOnIdleFunc );
- The same should be done for Events:
Application->Events->Add( MyEvent, MyEventHandler, MyEventAbandonHandler );
If this was done, the MessageLoop should be changed to:
TApplication::Run:
do ( HandleMessage() ) while( !Terminated );
TApplication::HandleMessage:
if( !ProcessMessage ) Idle();
TApplication::ProcessMessage:
while( 'there is any message present' )
'ProcessThisMessage';
TApplication::Idle:
bool Done = true;
for( int i = 0; i < OnIdle.Count(); i++ )
OnIdle[ i ]( this, Done );
if( Done )
{
DWORD NrOfEvents = Events->Count();
DWORD EventNr;
for(;;)
{
DWORD res = MsgWaitForMultipleObjectsEx( NrOfEvents,
Events->HandleArray, INFINITIE, QS_ALLINPU, MWMO_ALERTABLE );
EventNr = res - WAIT_OBJECT_0;
if( EventNr == NrOfEvents ) return;
if( EventNr < NrOfEvents )
{
Events[ EventNr ]->Handler();
Done = false;
}
else
{
EventNr = res - WAIT_ABANDONED_0;
if( EventNr < NrOfEvents )
{
Events[ EventNr ]->AbandonHandler();
Done = false;
}
else if( res != WAIT_IO_COMPLETION )
throw Exception( "Error...." );
}
}
}
Some of the functions used here are only for NT, but the code can be easily
modified to support both Win95/98 and NT !
OK, till here this is more a sugestion, but now my questions:
How can I override TApplication (with a version similar to the above code)
in my projects ???
I have now problem in writing a new class TApplication (or a class derifed
from them).
Unfortunaly this is pascal-code, it is a very big class, it is instantiated
in Controls.pas !
This means that i have to either modify Forms.pas and recompile the VCL
or either modify Controls.pas to instantiate TMyApplication istead of
TApplication.
The first approach assumes that I write my additional code in pascal
(
( I am familar in reading, but not so in writing pascal ).
Using the second approach I may write the class in C++, but how do I tell pascal to use it ??
(Beside the problem that some member of TApplication are declered privat instead of protected,
so it's not so simple to derife a class from it, when I need access to there members)
Any sugestions, solutions ?
Günter
Stefan Hoffmeister (TeamB)
>- This means that I can't handle Event's when the app is waiting for
>messages.
>- APC's are not called when waiting for Messages.
Correct.
>OK, I can set my own func to Application->OnIdle.
>This function in turn will call 'MsgWaitForMultipleObjectsEx' and handle
>Event's and/or APC's.
You could also use a secondary thread.
>How can I override TApplication (with a version similar to the above code)
>in my projects ???
You cannot.
>This means that i have to either modify Forms.pas and recompile the VCL
>or either modify Controls.pas to instantiate TMyApplication istead of
>TApplication.
This won't work very well - if at all. And it will be a dead end.
>Using the second approach I may write the class in C++, but how do I tell pascal to use it ??
You cannot.
>Any sugestions, solutions ?
Learn to live with it, sorry, and use a secondary thread for events.
--
Stefan Hoffmeister (TeamB) http://www.econos.de/
Please do apply judgement when sending email.
Joerg Schaible
MsgWaitForMultipleObjectsEx is unfortunately not available in Windows 95
--
Greetings, Jörg
--
BTW: It is normally better to answer to the group! For direct mail reply
exchange the ".A@T." by "@"
Günter Neiß
<3733f413...@forums.inprise.com>...
>: "Günter Neiß" <gne...@elekluft.com> wrote:
>
>>OK, I can set my own func to Application->OnIdle.
>>This function in turn will call 'MsgWaitForMultipleObjectsEx' and handle
>>Event's and/or APC's.
>
>You could also use a secondary thread.
That's exactly what I don't like to do !!!
I am familar using Thread's but they have a lot of dissatvatages (especialy
inside the VCL) :-(
- I can't use VCL-Objects from within the Thread without synchronizing
- Because this should be a general approach, I defenitly have to synchronize
the eventhandler
- because of the bad iplementation of the VCL-Class TThread the
Synchronize-Methode will block the Thread until the
Main(VCL)-Thread have processed the Synchronize-Message, witch in turmn
means that my event will be delayed till
the Main-Thread has reached it's message-loop.
So why using a second Thread ? In this case it is nothing else than an
unnessesary redirektion !
(If there was an implementation of 'Synchronize' that uses PostMessage
instead of Sendmessage the situation will be
a little bit better)
- Last but not least I don't like using Thread (in this environment) because
I already saw a lot of code that does using them
in an bad manner:
There are some 'Components' (DxTimer, MMTimer, Rs232-Classes) that use for
every instanse a seperate Thread.
In my app (using up to 10 simultanus Sockets, up to 8 simultanus
Rs232-Lines, and a lot of high presicion Timers) this
will lead to 20 to 30 Threads running. This is definitly the wrong
approach ! It consumes too manny resources.
For the Timers I wrote my own class that use one Thread for all instanses
of my High presicion Timers.
Now I am writing the Rs232-Class that should work in a similar manner.
Because the Rs232 Lines are already buffered
by the system, there is no need to handle incomming data at a higher
priority (as I do for the timers). So it is OK, to
handle them in the Main-MessageLoop... with will lead to the beginning of
this discussion ;-)
>>How can I override TApplication (with a version similar to the above code)
>>in my projects ???
>
>You cannot.
Why ? Please specify in more detail.
>>This means that i have to either modify Forms.pas and recompile the VCL
>>or either modify Controls.pas to instantiate TMyApplication istead of
>>TApplication.
>
>This won't work very well - if at all. And it will be a dead end.
Why ? Please specify in more detail.
>>Using the second approach I may write the class in C++, but how do I tell
pascal to use it ??
>
>You cannot.
As I had expected :-((((((((((
>>Any sugestions, solutions ?
>
>Learn to live with it, sorry, and use a secondary thread for events.
I can't (and wouldn't) as explained before.
>Stefan Hoffmeister (TeamB) http://www.econos.de/
>Please do apply judgement when sending email.
~~~~~~~~
Sorry doesn't know what 'judgement ' means. Can You tell me (possible in
german).
BTW.: I was a long time absent from the Borland forums (since the days
Compuserve opens for Internet).
After the CIS-Forums dies (especialy in quality), I found that the
News-Forums are not at the same
level as the CIS's was. But now I think that here are all the people that I
have seen in the CIS-Forums
before. Is this the same TeamB as it was on CIS ??
Günter Neiß
Günter Neiß
>... and additionally to Stefan's answer:
>MsgWaitForMultipleObjectsEx is unfortunately not available in Windows 95
As I wrote in my original msg, I know that.
But there is no problem (as I stated too) to detect what OS we are running
on and than calling either
'MsgWaitForMultipleObjectsEx' (NT) or 'MsgWaitForMultipleObjects'
(Win95/98).
In the pseudo code I wrote I don't include this to make the things more
clear.
>Greetings, Jörg
>--
>BTW: It is normally better to answer to the group! For direct mail reply
>exchange the ".A@T." by "@"
As I wrote in my answer to Stefan an new to News-Forums, so please explan
what You mean with:
>>exchange the ".A@T." by "@"<<
Günter
Stefan Hoffmeister (TeamB)
>Why ? Please specify in more detail.
Because you have no chance to construct it in time.
>Why ? Please specify in more detail.
Because you cannot replace the application object - it is tied very
tightly into the VCL.
>Sorry doesn't know what 'judgement ' means. Can You tell me (possible in
>german).
Gutbezahlte Arbeitsangebote, Spenden etc. sind willkommen. Ansonsten
bevorzuge ich es, keine email zu erhalten :-)
>Is this the same TeamB as it was on CIS ??
Yes.
--
Joerg Schaible
prevenhts that module from loading, since the loader of Win95 cannot resolve
the imports.
Günter Neiß
>: "Günter Neiß" <gne...@elekluft.com> wrote:
>
>>Why ? Please specify in more detail.
>
>Because you have no chance to construct it in time.
That's not the problem, because the source is present. I hvae to translate
PASCAL to C++ and than make the modifications. So where is the problem ??
>>Why ? Please specify in more detail.
>
>Because you cannot replace the application object - it is tied very
>tightly into the VCL
Nonsense. TApplication is a simple helper-class. It holds the primary
messageloop (and some other stuff).
If the VCL wasn't written in PASCAL, the replacement is verry simple (as I
had done a lot of time for parts of the C(++)-RTL).
Just write the unit/module that replaces the buildin one, using the same
names, add it to your project and let the linker use this instead of the
code inside the lib's.
BTW.: Your asnwers may be true for beginners ;-)
Günter
Günter Neiß
>Not that easy, calling MsgWaitForMultipleObjectsEx anywhere in the code
>prevenhts that module from loading, since the loader of Win95 cannot
resolve
>the imports.
You are right, but using:
#ifdef __WinNT__
....
MsgWaitForMultipleObjectsEx
....
#else
....
MsgWaitForMultipleObjects
....
#endif
will do everithing needed !
Günter
Stefan Hoffmeister (TeamB)
>That's not the problem, because the source is present. I hvae to translate
>PASCAL to C++ and than make the modifications. So where is the problem ??
You have to translate almost the complete VCL to C++. This of course
works. Good luck.
>Nonsense. TApplication is a simple helper-class. It holds the primary
>messageloop (and some other stuff).
Well, if you think so.
>If the VCL wasn't written in PASCAL, the replacement is verry simple (as I
>had done a lot of time for parts of the C(++)-RTL).
You could code your changes in Pascal.
>BTW.: Your asnwers may be true for beginners ;-)
It is true for everyone who is not willing to solve the problem in Object
Pascal. You are not willing to.
Let me suggest that you research this a bit, OK?
Günter Neiß
>: "Günter Neiß" <gne...@elekluft.com> wrote:
>
>>That's not the problem, because the source is present. I hvae to translate
>>PASCAL to C++ and than make the modifications. So where is the problem ??
>
>You have to translate almost the complete VCL to C++. This of course
>works.
TApplication is a Class that is located inside Forms.PAS.
The Implementation is about 1000 Lines.
The easiest way to modify it is copy Forms.PAS, make the changes and
recompile the VCL.
>>Nonsense. TApplication is a simple helper-class. It holds the primary
>>messageloop (and some other stuff).
>
>Well, if you think so.
As explaine above.
>>If the VCL wasn't written in PASCAL, the replacement is verry simple (as I
>>had done a lot of time for parts of the C(++)-RTL).
>
>You could code your changes in Pascal.
Because of the problems I see if I don't, I will do so.
As You may remember the changes are verry little, so I thing I will not run
in PASCAl-language-problems (I this case some of the other engniers in my
company my help ;-).
>>BTW.: Your asnwers may be true for beginners ;-)
>
>It is true for everyone who is not willing to solve the problem in Object
>Pascal. You are not willing to.
Not in prinziple, but if there is no other (easy) way ....
Günter
Alex Bakaev [TeamB]
good solution. To do what you are proposing the following should be
done:
if ( RunningOnNT )
MsgWaitForMultipleObjectsEx
else
MsgWaitForMultipleObjects
Alex
--
HotSend - portable documents technology
http://www.hotsend.com/
eFax - get your faxes via email - Free !
http://www.efax.com
Günter Neiß
>Not really <g>. With this approach you will need 2 binaries - hardly a
>good solution. To do what you are proposing the following should be
>done:
>
>if ( RunningOnNT )
> MsgWaitForMultipleObjectsEx
>else
> MsgWaitForMultipleObjects
>
Sorry, You didn't read the msg I answer to.
As Joerg Schaible wrote:
> calling MsgWaitForMultipleObjectsEx anywhere in the code
> prevenhts that module from loading, since the loader of Win95 cannot
> resolve the imports
So You realy need two different binaries (DLL/BPL)
- one for Win98
- one for NT
to solve the situation.
Günter
Stefan Hoffmeister (TeamB)
>So You realy need two different binaries (DLL/BPL)
>- one for Win98
>- one for NT
Rubbish.
Dynamically bind to one of the APIs. See GetProcAddress.
Günter Neiß
>: "Günter Neiß" <gne...@elkluft.com> wrote:
>
>>So You realy need two different binaries (DLL/BPL)
>>- one for Win98
>>- one for NT
>
>Rubbish.
>
>Dynamically bind to one of the APIs. See GetProcAddress.
Sorry, You mis something !
We are talking about two functions that are in the same DLL (but not present
in all versions of them).
I can't see how 'Dynamically binding' will solve this.
If there is a construct like:
if( using_dll1 ) Dll1Func();
else Dll2Func();
Dynamically binding may solve the problem, if you use:
if( using_dll1 ) LinkDll1();
else LinkDll2();
But here we are talking about 2 function that are part of the same DLL, but
the second function is only present in later versions of the dll (in this
case USER32.DLL from WinNt >= 4.0 or Win98, but not in User32.dll of Win95).
So at the moment You link in USER32.DLL (doesn't matter if You link it
dynamical or statical) all references into this library will be fixed by the
loader. If the loader finds a references that he couldn't solve You will get
an error and your app terminates.
If You know a way to catch this error, I am very interested how this works.
Günter
Günter Neiß
inprise news-server (but the T-online server does ?!?).
So if anyone got it twice, sorry...
Stefan Hoffmeister (TeamB) schrieb in Nachricht
As explaine above.
Günter
PS:: By reposting, I had an adidtional question:
In general there should be no problem in using mixed-language-modules.
Pascal does indeed use C-Modules (all Win32-API calls are such).
So the problem of using C-Modules in Pascal is more related to Objects
(Classes).
Doesn't Borland take this into account ?
I mean C-Builder is able to use Pascal-Classes from C-Modules, but not vise
versa ??
If this is true that will mean: CBuilder is able to use Componets written
for Delphi, but not the other way around !
I thing this question is important for Delphi/Pascal users, mabe I will ask
in the relevant forum, because I can't see why this shouldn't be possible.
But till now I don't know how to code the nessesary declarations in pascal.
Joerg Schaible
>- one for Win98
>- one for NT
And that would double the effort for Inprise to test. Basically you're
right, but Inprise had always the strategy to support a Win32 version, not a
separate Win95 and NT-Version. May be we'll have one day a pure NT (and
UNICODE) version, but unless M$ is not able to merge Windows to *one* base
system, you'll have to wait. Many tool vendors will (and have to due to
economic reasons) release versions running on both environments.
Chris Hill
<gne...@elekluft.com> wrote:
>Stefan Hoffmeister (TeamB) schrieb in Nachricht
><37364eff...@forums.inprise.com>...
>>: "Günter Neiß" <gne...@elkluft.com> wrote:
>>
>>>So You realy need two different binaries (DLL/BPL)
>>>- one for Win98
>>>- one for NT
>>
>>Rubbish.
>>
>>Dynamically bind to one of the APIs. See GetProcAddress.
>
>
>Sorry, You mis something !
>We are talking about two functions that are in the same DLL (but not present
>in all versions of them).
>
>I can't see how 'Dynamically binding' will solve this.
It will.
>If there is a construct like:
>
>if( using_dll1 ) Dll1Func();
> else Dll2Func();
>
>Dynamically binding may solve the problem, if you use:
>
>if( using_dll1 ) LinkDll1();
> else LinkDll2();
>
>
GetProcAddress is used at the _function_ level, the entire DLL is not
linked. It doesn't matter if the functions are in the same DLL or not
(of course a DLL must be loaded before GetProcAddress is used with
it).
For initialization:
if( using_dll1 )
UseGetProcAddress(); // on a system with DLL containing the function
else
InitializeOtherMeans(); // could also use GetProcAddress
Then when it comes time to use the two approaches:
if( using_dll1 )
UseDLLFunction();
else
UseSomeOtherMeans();
>So at the moment You link in USER32.DLL (doesn't matter if You link it
>dynamical or statical) all references into this library will be fixed by the
>loader. If the loader finds a references that he couldn't solve You will get
>an error and your app terminates.
There will be NO reference to the function in your code(in the sense
you[or the loader] are thinking of). You use GetProcAddress to link
to the function _at runtime_ if it is present. Then you call the
function through the pointer returned by GetProcAddress. The only
"reference" to the function is the string that is passed to
GetProcAddress, and the loader doesn't care about that.
Chris Hill
Chri...@aol.com
Stefan Hoffmeister (TeamB)
>I Resend this message, because it seems that it wasn't recocnised by the
>inprise news-server (but the T-online server does ?!?).
The Borland server does not take messages from foreign hosts.
>The easiest way to modify it is copy Forms.PAS, make the changes and
>recompile the VCL.
Yes, sure.
>So the problem of using C-Modules in Pascal is more related to Objects
>(Classes).
Yes.
[Classes]
>Doesn't Borland take this into account ?
Correct.
>I mean C-Builder is able to use Pascal-Classes from C-Modules, but not vise
>versa ??
C++Builder is a C++ compiler that uses C++-alike classes from C++ modules.
>I thing this question is important for Delphi/Pascal users, mabe I will ask
>in the relevant forum, because I can't see why this shouldn't be possible.
Easy: C++ is so convoluted that it is impossible to find matching
structures for some of the constructs in Object Pascal. And I personally
would fight every attempt to change the Object Pascal, just to make it
more compatible with C++.
>But till now I don't know how to code the nessesary declarations in pascal.
Exactly that is the point - see above.
Stefan Hoffmeister (TeamB)
>Sorry, You mis something !
I do not miss anything.
>So at the moment You link in USER32.DLL
You do not link.
>If You know a way to catch this error, I am very interested how this works.
Read about GetProcAddress and dynamic DLL loading. Check the VCL source
code for techniques demonstrating that.
Günter Neiß
Thanks for Your description.
>There will be NO reference to the function in your code(in the sense
>you[or the loader] are thinking of). You use GetProcAddress to link
>to the function _at runtime_ if it is present. Then you call the
>function through the pointer returned by GetProcAddress. The only
>"reference" to the function is the string that is passed to
>GetProcAddress, and the loader doesn't care about that.
OK, I understood so far.
But something isn't clear to me now:
In most cases I don't have to deal with this (GetProcAdress), I simply use
the function-name in
the code. The loading and linking will be done automatic by the runtime
system.
Does that mean: ???
that for every function (located in a dll) there is initaly only a stub.
If this stub will be called the first time it will resolve the link (using
GetProcAdress) and put this adress into the stub ?
Or is there a different 'resolving-logik' in that case ?
Günter
Günter Neiß
>: "Günter Neiß" <gne...@elekluft.com> wrote:
>
>Read about GetProcAddress and dynamic DLL loading. Check the VCL source
>code for techniques demonstrating that.
OK, Your answer together with the answer from Chris (and some investigation
in the help-files :-) make it clear to me.
Tomorrow I will make a test-prg to see if I had understood the whole thing.
Till now I am not shure what happens to the rest of the code (as far as I
know USER32.DLL is always bound, and I doesn't know til now how to set the
project-options to do a dynamic binding instead of static )
>>So at the moment You link in USER32.DLL
>You do not link.
That's my missunderstanding !
I mixed linking and binding and I assumed a dynamic linked DLL will resolve
all binding's to it at the moment it was loaded.
OK, I had to read a bit more about that...
Günter
Günter Neiß
>: "Günter Neiß" <gne...@elekluft.com> wrote:
>Easy: C++ is so convoluted that it is impossible to find matching
>structures for some of the constructs in Object Pascal. And I personally
>would fight every attempt to change the Object Pascal, just to make it
>more compatible with C++.
OK, I understood that You don't like to change PASCAL ....
But that's not what I mean.
Actualy the repesentations of (VCL-)PASCAL-Classes have some restrictions
(which have nothing to do with C++).
Some Examples:
- VCL-Classes must be constructed using new
- Try using 'this' in the initializing part of a constructor (before the
opne-bracket)....
'this' will be a pointer to the base-class, not to the class that was
actualy constructing
(this behavior is against ANSI-C !)
So in fact if you use the VCL there are restrictions/modifications to the
language (which you have to acept).
Now I can't see any reason why it shouldn't be possible to write a 'module'
in C++, compile it to a BPL and use it from PASCAL-modules.
If you do so you must follow the restrictions mentioned above plus some more
which are related to constructs that can't be transfered to pascal.
>>But till now I don't know how to code the nessesary declarations in
pascal.
>
>Exactly that is the point - see above.
I the above things are taken into account, there should be a way of doing
this.
The only 'extensions' to Object-Pascal I see was a way to define a class
outside a pacal-unit/module (like you can do for functions/procedures).
Günter
Stefan Hoffmeister (TeamB)
>Now I can't see any reason why it shouldn't be possible to write a 'module'
>in C++, compile it to a BPL and use it from PASCAL-modules.
Because you still would have to support templates, stack-based classes etc
etc etc.
>If you do so you must follow the restrictions mentioned above plus some more
>which are related to constructs that can't be transfered to pascal.
Nobody would use that.
Stefan Hoffmeister (TeamB)
>that for every function (located in a dll) there is initaly only a stub.
Please read some articles or books about the Win32 operating system,
especially the Win32 loader.
You will then understand a few things.
Chris Hill
wrote:
>In most cases I don't have to deal with this (GetProcAdress), I simply use
>the function-name in
>the code. The loading and linking will be done automatic by the runtime
>system.
Yes. All the functions you call this way (without GetProcAddress) are
listed in an import library. After your code is compiled, the linker
finds them in the import library and makes them imports in your EXE or
DLL file. You can see a list of all the functions your program
imports using a program such as tdump.
In this case, at runtime (during your program's startup), each library
is loaded and the entry points are resolved by the OS loader. If an
entry point cannot be located, the system won't successfully load the
process (it will exit).
The system is in control in this suituation.
If there are functions that aren't present on one of your target
platforms, you must use the GetProcAddress method so that
1) Your program can load if the platform that doesn't have the
function. (And provide an alternate way of doing things)
2) You _can_ call the function if the platform does support it.
>Does that mean: ???
>that for every function (located in a dll) there is initaly only a stub.
>If this stub will be called the first time it will resolve the link (using
>GetProcAdress) and put this adress into the stub ?
>
>Or is there a different 'resolving-logik' in that case ?
GetProcAddress works differently. There is not even a stub in your
EXE. Everything happens under the control of _your_ code. You load
the library, you get a function pointer using GetProcAddress and you
call the function via the pointer.
Summary:
WITHOUT GetProcAddress the loader handles the resolution of functions
at load time
WITH GetProcAddress the programmer handles the resolution of functions
at anytime (with the help of the OS)
Strictly speaking, the compiler/linker is also involved in the
non-GetProcAddress method. You make the call in a source language
like C++, and the compiler/linker generates machine code to call the
function. The compiler _can_ be designed to operate as you suggest.
Instead of using imports, it could generate code that calls
GetProcAddress before the function is called for the first time. The
compiler handles the resolution instead of the startup loader or the
programmer. The functions would only need to be present if the code
that calls them is executed. Only a very few functions, including
GetProcAddress, would need to be imported. Actually, I think MSVC++ 6
might implement this system (I don't have MSVC++ 6 but I've heard
people mention this).
Chris Hill
Chri...@aol.com
Günter Neiß
>: "Günter Neiß" <gne...@elkluft.com> wrote:
>
>>Now I can't see any reason why it shouldn't be possible to write a
'module'
>>in C++, compile it to a BPL and use it from PASCAL-modules.
>
>Because you still would have to support templates, stack-based classes etc
>etc etc.
As I sayed before, there is no need to support that.
In CBuilder you can't use 'stack-based classes' if your class is derived
from a pascal-class.
>>If you do so you must follow the restrictions mentioned above plus some
more
>>which are related to constructs that can't be transfered to pascal.
>
>Nobody would use that.
At least me ;-)
And I think that there are a lot more C(++) programmers that will use it.
(Think about the often found question about VCL porting to C++)
But if Your position is the position of Borland/Inprise I see why CBuilder
was not used in a lot of projects (in our company I know of at least 3, were
MS-C was used instead of CBuilder exactly because of this problems).
I am a long time a fan of the Borland-Compilers (starting with Turbo-C 1.0).
Till BC++3.1 they support the latest C++Features, the IDE was flexible to
use other tools too.
All this is gone with CBuilder :-(((((
I hope that Borland/Inprise will wake up and the next relases of CBuilder
will be more real C++ versions.
My personal favor is C++, anyone might favor Pascal, but if I buy a
C++Development tool it should be a real C++ one, not a Pascal-tool that
handles C++ more or less !
Günter
Stefan Hoffmeister (TeamB)
>As I sayed before, there is no need to support that.
>In CBuilder you can't use 'stack-based classes' if your class is derived
>from a pascal-class.
But you can *USE* stack-based classes in your class as well as the STL and
much more C++ features.
>At least me ;-)
>And I think that there are a lot more C(++) programmers that will use it.
>(Think about the often found question about VCL porting to C++)
Those who ask for a C++ VCL hate Pascal. They will never accept
>But if Your position is the position of Borland/Inprise
TeamB is in on way associated with Borland; we do not represent Borland -
see http://www.TeamB.com/. This is all *my* opinion.
Perhaps you got the wrong picture: I am a Delphi fan, I would *LOVE* to be
able to conveniently use C++ code from Delphi. Alas, I don't see it
happen.
>I see why CBuilder
>was not used in a lot of projects (in our company I know of at least 3, were
>MS-C was used instead of CBuilder exactly because of this problems).
*Which* problem?
>I am a long time a fan of the Borland-Compilers (starting with Turbo-C 1.0).
>Till BC++3.1 they support the latest C++Features, the IDE was flexible to
>use other tools too.
>All this is gone with CBuilder :-(((((
C++Builder is the most ANSI C++ compliant compiler you can get for Win32.
Where is that problem???
Which other tools are gone???
>My personal favor is C++, anyone might favor Pascal, but if I buy a
>C++Development tool it should be a real C++ one, not a Pascal-tool that
>handles C++ more or less !
Again, C++Builder is the most ANSI C++ compliant compiler you can get for
Win32.
You don't *HAVE* to use Pascal.
Sorry, Guenter, but I am really having problems to understand all your
complaints:
* You have an excellent C++ compiler.
* You have a powerful application framework that can be used from
C++ - which is incidentally written in Object Pascal
I accept that the project manager has quite some deficiencies.
Günter Neiß
>GetProcAddress works differently. There is not even a stub in your
>EXE. Everything happens under the control of _your_ code. You load
>the library, you get a function pointer using GetProcAddress and you
>call the function via the pointer.
Ok, that's clear.
>The compiler _can_ be designed to operate as you suggest.
>Instead of using imports, ....
~~~~~~
I got it (I hope): function-references that a listed in the imports-section
are resolved by the loader
(the other not).
Now it's clear that it doesn't matter that the RTL already imports functions
from USER32.DLL (with in turn means, that USER32.DLL was already loaded when
my code is executed).
To solve the problem indicated at the beginning of this discussion, I have
to do the following (omiting error-checking):
Before using the function in question:
// Define a Pointer(Type) to the function in question
typedef DWORD WINAPI ( * TFPtr ) (DWORD,LPHANDLE,DWORD,DWORD,DWORD);
~~~~~~
// Should it be WINAPI or DLLIMPORT ?? (nothing noted in Win32-SDK)
// Get the handle of the DLL
HMODULE User32Handle = GetModuleHandle( "USER32.DLL" );
// Get the Fuction-Adr (cast it to the right type)
TFPtr FPtr = (TFPtr) GetProcAddress( User32Handle,
"MsgWaitForMultipleObjectsEx" );
At the point I call the function:
// An now we can call the function
DWORD result = FPtr(....);
Maybe I should use 'LoadLibrary' instead of 'GetModuleHandle',
because this will increment the reference-count for the dll ?!?
But from the prev. discussion I assume that the DLL was loaded (mapped into
the process adr-space) and remains it till the process terminates.
Günter
Chris Hill
wrote:
>To solve the problem indicated at the beginning of this discussion, I have
>to do the following (omiting error-checking):
>
>Before using the function in question:
>
>// Define a Pointer(Type) to the function in question
>typedef DWORD WINAPI ( * TFPtr ) (DWORD,LPHANDLE,DWORD,DWORD,DWORD);
> ~~~~~~
>// Should it be WINAPI or DLLIMPORT ?? (nothing noted in Win32-SDK)
I think WINAPI is fine.
>Maybe I should use 'LoadLibrary' instead of 'GetModuleHandle',
>because this will increment the reference-count for the dll ?!?
>
You can use GetModuleHandle for USER32.DLL because as you noted the
RTL imports functions from it. You don't need to increment the
reference count because USER32.DLL will remain loaded.
If you were dealing with a non-system DLL, you would probably want to
use LoadLibrary.
Chris Hill
Chri...@aol.com
Günter Neiß
>Those who ask for a C++ VCL hate Pascal. They will never accept
I don't think so. In my opinion a C++ VCL has the advantage that you only
have to now one language (in deep) to modify things of the RTL/VCL.
But unfortunaly I think You are right, Borland will not port it :-(((
>TeamB is in on way associated with Borland; we do not represent Borland -
>see http://www.TeamB.com/. This is all *my* opinion.
I know that (that's why I ask before if TeamB is the same as on CIS).
But I assume that You know a lot about the position of Borland (in that
case).
>Perhaps you got the wrong picture: I am a Delphi fan, I would *LOVE* to be
~~~~~~~~~~~~~~
As I read in the middle of Your words (hope this german idiom makes sense to
You).
>able to conveniently use C++ code from Delphi. Alas, I don't see it
>happen.
I agree !
>>I see why CBuilder
>>was not used in a lot of projects (in our company I know of at least 3,
were
>>MS-C was used instead of CBuilder exactly because of this problems).
>
>*Which* problem?
Problems using NON-Borland/NON-Borland prefered tools.
Case-Tools, COFF-Format....
>>I am a long time a fan of the Borland-Compilers (starting with Turbo-C
1.0).
>>Till BC++3.1 they support the latest C++Features, the IDE was flexible to
>>use other tools too.
>>All this is gone with CBuilder :-(((((
>
>C++Builder is the most ANSI C++ compliant compiler you can get for Win32.
>Where is that problem???
>
>Which other tools are gone???
The possibility to extend the IDE with other 'translaters'.
Ex.: I am using BC++5.02 to compile a project, that includes PC-Code,
DSP-Code and Code for another µP.
I simply at the compilers/linker for the other µP's/DSP to the Tools,
declare them as the default translators for the related extensions and
then......
Just one F9 will produce all files....
If You know a way to do this with CBuilder too, I am verry happy to hear
about.
>Again, C++Builder is the most ANSI C++ compliant compiler you can get for
>Win32.
As long as You do not use the VCL !
Ex.: __closure is implemented as a keyword, to be ANSI compliant it should
have been implemented as a class !
>You don't *HAVE* to use Pascal.
As long as You do not extend the features of the VCL/RTL ;-))
(with is a thing I have done in a lot of my projects)
Remember my prinzipal environment is real-time processing with low level Hw
access.
Almost all my projects require a specialized Hw (with I design).
Some days ago this was done under DOS, but now the coustomers like to have
an easy/common user-interface
(like Windows supplies).
Because my main works lies in the implementation of the functionality I am
verry happy to be able to use a RAID tool for the user-interface. But
because of the other requironments (as explained in this discussion) there
will be some extensions to the RTL/VCL needed (to reach the goal in speed)
und here it will be a lot easier to me having a development tool that is
totaly in C(++).
Some more Ex.: in BC++1.0 (? i think) I found, solve and report a bug in the
code for _harderror().
When I get BC++3.1 the bug was still present (Bug-Reports and their handling
are not only a nightmare at Borland, no response).
I bet that I am unable to do this if the RTL was written in Pascal !
>* You have an excellent C++ compiler.
right (aparent from the optimisation quality)
>* You have a powerful application framework that can be used from
> C++ - which is incidentally written in Object Pascal
right
>I accept that the project manager has quite some deficiencies.
agree, he could be better
But I have no:
- profiler
- I miss debuger-features (TD32 can't handle VCL-files)
- I can't integrate my project into the case-tool used in other
(NON-Borland/Unix) Projects.
Not to be missunderstood. I still find that CBuilder is a good tool, but it
can be better and whenever I had an idea to do so, this should be discussed
with some other users and finally used as a sugestion to Borland.
Günter
Stefan Hoffmeister (TeamB)
>But I assume that You know a lot about the position of Borland (in that
>case).
This assumption is wrong.
>The possibility to extend the IDE with other 'translaters'.
>Ex.: I am using BC++5.02 to compile a project, that includes PC-Code,
>DSP-Code and Code for another µP.
Well, write an expert for the Open Tools API. Extremely flexible.
>Just one F9 will produce all files....
Yep. Open Tools API.
>When I get BC++3.1 the bug was still present (Bug-Reports and their handling
>are not only a nightmare at Borland, no response).
This should have changed dramatically.
>I bet that I am unable to do this if the RTL was written in Pascal !
The RTL is in C(++) and Pascal.
>But I have no:
>- profiler
Intel VTune.
>- I miss debuger-features (TD32 can't handle VCL-files)
Wrong.
>- I can't integrate my project into the case-tool used in other
>(NON-Borland/Unix) Projects.
OEW (http://www.isg.de/ - excellent tool)
>Not to be missunderstood. I still find that CBuilder is a good tool, but it
>can be better and whenever I had an idea to do so, this should be discussed
>with some other users and finally used as a sugestion to Borland.
Yes. Indeed. Please submit all feature requests at
http://www.borland.com/devsupport/bugs/bug_reports.html
This is the *only* way to make sure that somebody from Borland reads it.
Thanks!
Günter Neiß
>Well, write an expert for the Open Tools API. Extremely flexible.
~~~~~~~~~~~~
Never heard about that, were can I found the description/help for that ?
A search in openhelp doesn't find anything about that :-(
BTW.: Just while searching, I found that the way I use in BC++5.02 works in
BCB3 !
Maybe I tried to use it in BCB1, it wasn't present,... and than I don't try
it for BCB3 again, still thinking that it's not present in BCB.
Maybe I didn't find it because I am using a german version of BCB (at work)
and the US version (at home). I choose this, because both version have
advantages and disadvantages:
- an US version on a german OS leads to some problems
- a german version on a german OS should be perferct, but in fact some of
the description in the help/readme/doc was translated so bad, that you
cannot understand was was meant. For that reason, I prefer using the
US-help/doc, the germans are OK if you know how it works and need only some
'reminders'.
>>When I get BC++3.1 the bug was still present (Bug-Reports and their
handling
>>are not only a nightmare at Borland, no response).
>
>This should have changed dramatically.
I will see....
If You look at Thread 'Array of __closure's ???' in forum
'cppbuilder.language',
you'll see a bug I found (I think) in BCB3 (in BCB4 it seams to be fixed).
Tomorrow I will submit a bug-report (I nobody tells me till than, that the
fix is present anywhere) and than I will see how long it takes to get an
answer.
>>I bet that I am unable to do this if the RTL was written in Pascal !
>
>The RTL is in C(++) and Pascal.
I am talking about the RTL of BC++3.1 (with was ASM and a C only).
And if this RTL was not written in ASM/C I couldn't find the bug, because I
am not familar enougth with Pascal.
>>But I have no:
>>- profiler
>
>Intel VTune.
Not the point:
In prev. Versions of Turbo/Borland-C it was included (and in some concurrent
products of BCB today)
>>- I miss debuger-features (TD32 can't handle VCL-files)
>
>Wrong.
Sorry, whenever I load a (VCL-)app into TD32 it says something like 'invalid
exe/debug-info'
>>- I can't integrate my project into the case-tool used in other
>>(NON-Borland/Unix) Projects.
>
>OEW (http://www.isg.de/ - excellent tool)
Again, not the point:
What I meant is that we already use a case-tool, but till now doesn't see a
chance to integrate BCB into this environment.
Maybe You statement about Open Tools API solve this, but again why isn't
there any description...
BC++3.1 came with 10kg Documentation, BCB3 with 15pages :-((
(And I hate to read documentation at the screen)
Günter
Stefan Hoffmeister (TeamB)
>Stefan Hoffmeister (TeamB) schrieb in Nachricht
><373034fe...@forums.inprise.com>...
>
>>Well, write an expert for the Open Tools API. Extremely flexible.
> ~~~~~~~~~~~~
>Never heard about that, were can I found the description/help for that ?
E:\BCB4\Source\ToolsAPI
and
The overwhelming majority of documentation and sample for the Open Tools
API is in Pascal, sorry.
>- an US version on a german OS leads to some problems
Not for me (Windows NT 4.0, exclusively US English versions)
I make it a point to ignore the ridiculous efforts to translate the
English documentation to some incomprehensible German.
>(in BCB4 it seams to be fixed).
>Tomorrow I will submit a bug-report (I nobody tells me till than, that the
>fix is present anywhere) and than I will see how long it takes to get an
>answer.
I would not expect an answer, though I agree that it would be nice.
>Not the point:
>In prev. Versions of Turbo/Borland-C it was included (and in some concurrent
>products of BCB today)
There is no Borland 32 bit profiler - and there never has been one.
>Sorry, whenever I load a (VCL-)app into TD32 it says something like 'invalid
>exe/debug-info'
Does not seem to happen for me.
>BC++3.1 came with 10kg Documentation, BCB3 with 15pages :-((
>(And I hate to read documentation at the screen)
You can order printed manuals, I am certain. I once ordered the printed
OWL 5 docs - for obvious reasons <g>