Re: Re:

Sorry about that, my mistake, the patched method goes like this:

procedure DeallocateHWnd(Wnd: HWND);
var
  Instance: Pointer;
begin
  Instance := Pointer(GetWindowLong(Wnd, GWL_WNDPROC));
  if Instance <> @DefWindowProc then
  begin
    { make sure we restore the default
      windows procedure before freeing memory }
    SetWindowLong(Wnd, GWL_WNDPROC, Longint(@DefWindowProc));
    FreeObjectInstance(Instance);
  end;
  DestroyWindow(Wnd);

end;





"Andreas Hausladen" <AndreasDOTHausladen@gObviousToBeRemovedmx.de> wrote in 
message news:99620@forums.codegear.com...
> Anders Evensen wrote:
>
>> The problem is that we need to change the following method as
>> described:
>
> As described where? The function you posted is exactly the
> Classes.DeallocateHWnd function with not a single character changed.
>
>
> -- 
> Regards,
>
> Andreas Hausladen
0
Anders
4/1/2009 4:17:04 PM
embarcadero.delphi.non-tech 5933 articles. 1 followers. Follow

11 Replies
1724 Views

Similar Articles

[PageSpeed] 35
Get it on Google Play
Get it on Apple App Store

Anders Evensen wrote:

> Sorry about that, my mistake, the patched method goes like this:
> 
> procedure DeallocateHWnd(Wnd: HWND);
> var
>  Instance: Pointer;
> begin
>  Instance := Pointer(GetWindowLong(Wnd, GWL_WNDPROC));
>  if Instance <> @DefWindowProc then
>  begin
>    { make sure we restore the default
>      windows procedure before freeing memory }
>    SetWindowLong(Wnd, GWL_WNDPROC, Longint(@DefWindowProc));
>    FreeObjectInstance(Instance);
>  end;
>  DestroyWindow(Wnd);
> 
> end;

Why did you make this change? What problem are you trying to solve?
Have you reported to Quality Central with a clear, concise test case?

From simple a comparison between the two methods, the net effect of
either one is the same. The only reason I can see is that your WndProc
hook (from a previous call to AllocateHWnd) isn't calling DefWindowProc
and this is to ensure that DefWindowProc is always called during
destruction? In that case, the problem may not be with this method but
possibly your usage of AllocateHWnd and DeallocateHWnd?

-- 
Allen Bauer
CodeGear/Embarcadero
Chief Scientist
http://blogs.codegear.com/abauer
0
Allen
4/1/2009 4:50:05 PM
> Allen Bauer
> CodeGear/Embarcadero
> Chief Scientist

Hi Allen,

what was the turn of events at CodeGear today. I hope it hasnt stopped you from getting
on with the Pascal binding to that large C++ library. :-)

regards

David
0
David
4/1/2009 4:59:10 PM
David Champion wrote:

> > Allen Bauer
> > CodeGear/Embarcadero
> > Chief Scientist
> 
> Hi Allen,
> 
> what was the turn of events at CodeGear today. 

The economy sucks... some belt-tightening and working toward weathering
the current economic storm.

> I hope it hasnt
> stopped you from getting on with the Pascal binding to that large C++
> library. :-)

<blink>

-- 
Allen Bauer
CodeGear/Embarcadero
Chief Scientist
http://blogs.codegear.com/abauer
0
Allen
4/1/2009 5:59:43 PM
Allen Bauer wrote:
> 
> The economy sucks... some belt-tightening and working toward weathering
> the current economic storm.
> 

Any announcements???

David Erbas-White
0
David
4/1/2009 6:20:34 PM
David Erbas-White wrote:

> Allen Bauer wrote:
> > 
> > The economy sucks... some belt-tightening and working toward
> > weathering the current economic storm.
> > 
> 
> Any announcements???

Nope. The company is very well positioned to continue to execute on our
plans. Sounds weasely, I know, but it is the truth. In addition, I must
say that compared to past Borland shenanigans under tough
circumstances, Embarcadero's management is far more proactive at
protecting the bottom line *without* eviscerating certain key products
to achieve it.

-- 
Allen Bauer
CodeGear/Embarcadero
Chief Scientist
http://blogs.embarcadero.com/abauer
0
Allen
4/1/2009 7:14:00 PM
Allen Bauer wrote:

> In addition, I must
> say that compared to past Borland shenanigans under tough
> circumstances, Embarcadero's management is far more proactive at
> protecting the bottom line without eviscerating certain key products
> to achieve it.

<applause>

-- 
Dave Nottage [TeamB]
0
Dave
4/1/2009 9:50:45 PM
"Allen Bauer" <abauer@spicedham.codegear.com> wrote in message 
news:100060@forums.codegear.com...
> Anders Evensen wrote:
>
>> Sorry about that, my mistake, the patched method goes like this:
>>
>> procedure DeallocateHWnd(Wnd: HWND);
>> var
>>  Instance: Pointer;
>> begin
>>  Instance := Pointer(GetWindowLong(Wnd, GWL_WNDPROC));
>>  if Instance <> @DefWindowProc then
>>  begin
>>    { make sure we restore the default
>>      windows procedure before freeing memory }
>>    SetWindowLong(Wnd, GWL_WNDPROC, Longint(@DefWindowProc));
>>    FreeObjectInstance(Instance);
>>  end;
>>  DestroyWindow(Wnd);
>>
>> end;
>
> Why did you make this change? What problem are you trying to solve?
> Have you reported to Quality Central with a clear, concise test case?
>
> From simple a comparison between the two methods, the net effect of
> either one is the same. The only reason I can see is that your WndProc
> hook (from a previous call to AllocateHWnd) isn't calling DefWindowProc
> and this is to ensure that DefWindowProc is always called during
> destruction? In that case, the problem may not be with this method but
> possibly your usage of AllocateHWnd and DeallocateHWnd?
>
> -- 
> Allen Bauer
> CodeGear/Embarcadero
> Chief Scientist
> http://blogs.codegear.com/abauer


The fix was applied because we had problems with COM+ server application. 
From time to time we had errors in the event log:

Faulting application dllhost.exe, version 5.2.3790.0, faulting module 
unknown, version 0.0.0.0, fault address 0x00000000.

The errors turned out to happen when our dll was unloaded by the dllhost 
process. This is long time ago, and we do not remember all the details here, 
but however we ended up applying the change to the DeallocateHWnd(...) 
method, and the errors did not occur any more.

-Anders Evensen
0
Anders
4/2/2009 7:36:48 AM
> {quote:title=Allen Bauer wrote:}{quote}
> Anders Evensen wrote:
> 
> > Sorry about that, my mistake, the patched method goes like this:
> > 
> > procedure DeallocateHWnd(Wnd: HWND);
> > var
> >  Instance: Pointer;
> > begin
> >  Instance := Pointer(GetWindowLong(Wnd, GWL_WNDPROC));
> >  if Instance <> @DefWindowProc then
> >  begin
> >    { make sure we restore the default
> >      windows procedure before freeing memory }
> >    SetWindowLong(Wnd, GWL_WNDPROC, Longint(@DefWindowProc));
> >    FreeObjectInstance(Instance);
> >  end;
> >  DestroyWindow(Wnd);
> > 
> > end;

> From simple a comparison between the two methods, the net effect of
> either one is the same. 

Not quite. The patched function makes sure that the messages $90, WM_DESTROY, WM_NCDESTROY will not arrive at the windowproc. That would be a bug.

@Anders:
Could it be that your window proc has a problem when it gets any of these two messages? Unless you're absolutely sure that nothing in your code needs to do some clean up when it gets those messages, I'd recommend that you fix the original problem instead.
0
Sebastian
4/2/2009 9:25:20 AM
Sebastian Zierer wrote:

> > From simple a comparison between the two methods, the net effect of
> > either one is the same. 
> 
> Not quite. The patched function makes sure that the messages $90,
> WM_DESTROY, WM_NCDESTROY will not arrive at the windowproc. That
> would be a bug.

Uh... that is what I said. I was asking if the user-supplied window
proc wasn't allowing all the messages through to the DefWindowProc.
That would include WM_DESTROY and WM_NCDESTROY.
 
> @Anders:
> Could it be that your window proc has a problem when it gets any of
> these two messages? Unless you're absolutely sure that nothing in
> your code needs to do some clean up when it gets those messages, I'd
> recommend that you fix the original problem instead.

In Anders' case, the dll in which his window proc resides has been
unloaded via COM+, at which point it would be a little tricky to have
non-existant code forward along a message to DefWindowProc ;-).

-- 
Allen Bauer
CodeGear/Embarcadero
Chief Scientist
http://blogs.codegear.com/abauer
0
Allen
4/2/2009 3:34:29 PM
Anders Evensen wrote:

> "Allen Bauer" <abauer@spicedham.codegear.com> wrote in message
> news:100060@forums.codegear.com...
> > Anders Evensen wrote:
> > 
> > > Sorry about that, my mistake, the patched method goes like this:
> > > 
> > > procedure DeallocateHWnd(Wnd: HWND);
> > > var
> >> Instance: Pointer;
> > > begin
> >> Instance := Pointer(GetWindowLong(Wnd, GWL_WNDPROC));
> >> if Instance <> @DefWindowProc then
> >> begin
> >>   { make sure we restore the default
> >>     windows procedure before freeing memory }
> >>   SetWindowLong(Wnd, GWL_WNDPROC, Longint(@DefWindowProc));
> >>   FreeObjectInstance(Instance);
> >> end;
> >> DestroyWindow(Wnd);
> > > 
> > > end;
> > 
> > Why did you make this change? What problem are you trying to solve?
> > Have you reported to Quality Central with a clear, concise test
> > case?
> > 
> > From simple a comparison between the two methods, the net effect of
> > either one is the same. The only reason I can see is that your
> > WndProc hook (from a previous call to AllocateHWnd) isn't calling
> > DefWindowProc and this is to ensure that DefWindowProc is always
> > called during destruction? In that case, the problem may not be
> > with this method but possibly your usage of AllocateHWnd and
> > DeallocateHWnd?
> > 
> > --  Allen Bauer
> > CodeGear/Embarcadero
> > Chief Scientist
> > http://blogs.codegear.com/abauer
> 
> 
> The fix was applied because we had problems with COM+ server
> application. From time to time we had errors in the event log:
> 
> Faulting application dllhost.exe, version 5.2.3790.0, faulting module
> unknown, version 0.0.0.0, fault address 0x00000000.
> 
> The errors turned out to happen when our dll was unloaded by the
> dllhost process. This is long time ago, and we do not remember all
> the details here, but however we ended up applying the change to the
> DeallocateHWnd(...) method, and the errors did not occur any more.

I would contend in that case that "fixing" DeallocateWnd was merely
treatng the symptom and not the root cause. Either the dll is being
unloaded too soon, or your cleanup code isn't being run or doing all
that it needs to.

Another thing to really look at for COM+ applications is that you
should not be causing libraries to be loaded from within the
initialization sections of units within a DLL. This can implicitly
happen by accessing or instantiating a COM+ class/object. We've had
several similar reports and it has all boiled down to doing dodgy
things in initialization sections. In a few cases, yes, our code was
not quite doing it right.

-- 
Allen Bauer
CodeGear/Embarcadero
Chief Scientist
http://blogs.codegear.com/abauer
0
Allen
4/2/2009 3:40:28 PM
Thanks, we will have a walk through of the initialization sections (quite a 
few including 3rd part libraries.)

By do also strange COM surrogate errors from windows from time to time. On 
my developer desktop running this COM+ application serever I have notices 
that it tent to happen when IE is started, may be some windows message being 
broadcasted all appication that triggers it?



"Allen Bauer" <abauer@spicedham.codegear.com> wrote in message 
news:100680@forums.codegear.com...
> Anders Evensen wrote:
>
>> "Allen Bauer" <abauer@spicedham.codegear.com> wrote in message
>> news:100060@forums.codegear.com...
>> > Anders Evensen wrote:
>> >
>> > > Sorry about that, my mistake, the patched method goes like this:
>> > >
>> > > procedure DeallocateHWnd(Wnd: HWND);
>> > > var
>> >> Instance: Pointer;
>> > > begin
>> >> Instance := Pointer(GetWindowLong(Wnd, GWL_WNDPROC));
>> >> if Instance <> @DefWindowProc then
>> >> begin
>> >>   { make sure we restore the default
>> >>     windows procedure before freeing memory }
>> >>   SetWindowLong(Wnd, GWL_WNDPROC, Longint(@DefWindowProc));
>> >>   FreeObjectInstance(Instance);
>> >> end;
>> >> DestroyWindow(Wnd);
>> > >
>> > > end;
>> >
>> > Why did you make this change? What problem are you trying to solve?
>> > Have you reported to Quality Central with a clear, concise test
>> > case?
>> >
>> > From simple a comparison between the two methods, the net effect of
>> > either one is the same. The only reason I can see is that your
>> > WndProc hook (from a previous call to AllocateHWnd) isn't calling
>> > DefWindowProc and this is to ensure that DefWindowProc is always
>> > called during destruction? In that case, the problem may not be
>> > with this method but possibly your usage of AllocateHWnd and
>> > DeallocateHWnd?
>> >
>> > --  Allen Bauer
>> > CodeGear/Embarcadero
>> > Chief Scientist
>> > http://blogs.codegear.com/abauer
>>
>>
>> The fix was applied because we had problems with COM+ server
>> application. From time to time we had errors in the event log:
>>
>> Faulting application dllhost.exe, version 5.2.3790.0, faulting module
>> unknown, version 0.0.0.0, fault address 0x00000000.
>>
>> The errors turned out to happen when our dll was unloaded by the
>> dllhost process. This is long time ago, and we do not remember all
>> the details here, but however we ended up applying the change to the
>> DeallocateHWnd(...) method, and the errors did not occur any more.
>
> I would contend in that case that "fixing" DeallocateWnd was merely
> treatng the symptom and not the root cause. Either the dll is being
> unloaded too soon, or your cleanup code isn't being run or doing all
> that it needs to.
>
> Another thing to really look at for COM+ applications is that you
> should not be causing libraries to be loaded from within the
> initialization sections of units within a DLL. This can implicitly
> happen by accessing or instantiating a COM+ class/object. We've had
> several similar reports and it has all boiled down to doing dodgy
> things in initialization sections. In a few cases, yes, our code was
> not quite doing it right.
>
> -- 
> Allen Bauer
> CodeGear/Embarcadero
> Chief Scientist
> http://blogs.codegear.com/abauer
0
Anders
4/3/2009 10:07:46 PM
Reply:

Similar Artilces:

RE : RE : RE : RE : Regular expressions
Here is a sample of what your piece of code returns on my Aix box. 44520 -> /prog/gena/8.1.1/bin/dispatch 44650 -> reproject 45176 -> aioserver 45432 -> aioserver 45724 -> -ksh 46002 -> /bin/bsh 46232 -> /usr/dt/bin/dtterm 46584 -> /usr/bin/ksh 46820 -> /usr/dt/bin/ttsession 47060 -> /bin/bsh 47304 -> /usr/dt/bin/dtlogin 47396 -> /usr/dt/bin/dtterm 47722 -> dtfile 47942 -> /usr/dt/bin/dtsession 48272 -> dtfile 48568 -> ora_cjq0_gist 48758 -> gxtrackd 49032 -> dtwm 49330 -> /usr/lib/lpd/pio/etc/piohpnpf 49592 -> b...

Re: Re: Re: RE: Perl Question: Optimization
--Next_1099583965---0-202.54.124.178-6735 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Partly right. Here is the code snippet.=0A=0A#! /opt/perl5/bin/perl=0A=0Aus= e strict;=0Ause DBI;=0Amy $datasource =3D "dbi:Oracle:";=0A=0Amy $db_userna= me1 =3D "dbuser";=0Amy $db_password1 =3D "dbpswd";=0Amy $db_sid =3D "dbsid"= ;=0A=0Amy $db_username2 =3D "dbuser";=0Amy $db_password2 =3D "dbpswd";=0Amy= $db_sid2 =3D "dbsid2";=0A=0A=0Asetup_db_cons();=0A...

RE: Re: [wxperl-users] Re: Re: EVT_QUERY_END_SESSION
you putted the EVT_CLOSE to the wrong place... or do you have a reason why you need it to be there? $app ist not the window, but you could use EVT_CLOSE on $frame too. i changed your minimal sample that it works. hope it helps greeting Marco ---- use Wx; ########################### package MyApp; use strict; use vars qw(@ISA); @ISA=qw(Wx::App); sub OnInit { my( $this ) = @_; my( $frame ) = MyFrame->new( "Minimal wxPerl app", Wx::Point->new( 50, 50 ), Wx::Size->new( 450, 350 ) ); ...

RE : RE : RE : RE : Regular expressions #2
No worries :-) It works now, thanks a lot :-) Best regards, Steve Hemond Programmeur Analyste / Analyst Programmer Smurfit-Stone, Ressources Foresti=E8res La Tuque, P.Q. Tel.: (819) 676-8100 X2833 shemond@smurfit.com=20 > -----Original Message----- > From: drieux [mailto:drieux@wetware.com]=20 > Sent: Wednesday, December 17, 2003 1:38 PM > To: Perl Perl > Subject: Re: RE : RE : RE : Regular expressions >=20 >=20 >=20 > On Dec 17, 2003, at 10:24 AM, drieux wrote: >=20 > > > > open(PS, "ps -efA|") or...

Re: Re: Re: Re: cross cluster read fails
--Boundary_(ID_HDBIpKP7HBB79jluGvYvuw) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT Content-disposition: inline �Hi Alan One more thing before we go further :) I wrote a simple perl script that accepts a file name, prints it out, opens the file (dies if open unsuccessful or prints �open successful�) 1>I passed my local directory filename, it prints �open successful� 2> Now I just add �abcd::� in front of it, and the perl script fails with Remote node is unknown D...

Re: Re: Re: RE: capture a website and process its data
--Next_1077222091---0-202.54.124.153-17281 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Rob,=0AI implemented your code and it gave perfectly desired answers. Bu= t I couldn't understand most of it. So, currently I went ahead with Dan's t= ips on my code only and would try to understand your code later after I mee= t a deadline for a small project of mine in college for tomorrow! So, no qu= estions as of now. =0A=0Acheers.=0AK(ay).=0A=0A=0AOn Thu, 19 Feb 2004 Rob D= ixon wrote :=0A>Scott E Robinso...

RE: Re: Re: Sub not working as it should
You don't need to be sorry - it's the right choice ;-) Philipp > -----Original Message----- > > I am sorry I am migrating over to perl (love the built > in debugger) > --- Saadat Saeed <saadat_saeed@yahoo.com> wrote: > > Thanks for the quick reponse - looks like I confuse > > my > > vbscript skills a bit... I am new to perl and am > > migrating over to vbscript! > > > > Regards > > > > > > --- Jeff 'japhy' Pinyan <japhy@perlmonk.org> wrote: > > > On Jan 21, Saadat S...

RE: RE: Re: Tri-grams?
------_=_NextPart_001_01C6380E.13FCCC91 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable -----Original Message----- From: amit hetawal [mailto:amit_h123@rediffmail.com] Sent: Wednesday, February 22, 2006 16:00 To: Wagner, David --- Senior Programmer Analyst --- WGO Subject: Re: RE: Re: Tri-grams? hi there the sequnce with alpha _ _ is valid but not _ _ _ I replaced the 4 four lines in your program with the following four line= s. =20 next if ( $char !~ /[a-z]/i ); my $char2 =3D substr $_, $ii+1, 1; ...

RE : RE : RE : Regular expressions
I am issuing this command on an Aix box and running allright :-) Forgive my curiosity.. are you running Solaris on a x86 box?=20 Steve Hemond Programmeur Analyste / Analyst Programmer Smurfit-Stone, Ressources Foresti=E8res La Tuque, P.Q. Tel.: (819) 676-8100 X2833 shemond@smurfit.com=20 > -----Original Message----- > From: drieux [mailto:drieux@wetware.com]=20 > Sent: Wednesday, December 17, 2003 1:14 PM > To: Perl Perl > Subject: Re: RE : RE : Regular expressions >=20 >=20 >=20 > On Dec 17, 2003, at 8:47 AM, Hemond, Steve wrote: ...

Re: Re-inventing the wheel [was RE: Why not gmp? [was Re: pdd14 -- bignums] ]
Simon Cozens <simon@netthink.c To: Shlomi Fish <shlomif@vipe.technion.ac.il> o.uk> cc: perl6-internals@perl.org ...

RE: RE: RE: RE: [wxperl-users] wxTreeCtrl, edit an treeItem
>>Found a fix ( I hope ); download the modified wx22_9.dll from >>http://wwwstud.dsi.unive.it/~mbarbon/wx/wx22_9.dll.gz >>uncompress it and put it in $PERL/site/lib/auto/Wx >>( make a backup of the original one, of course ). >>This fixes your problem with tree control, but may introduce >>new ones ( it is a fix backported from wxWIndows 2.3 ). >> >>Regards >>Mattia > >hey thanks man! >i had no time to work on my application but i checked the wxwindows >mailinglist archive. you asked for a code change as workaround......

RE : RE : RE : Regular expressions #2
drieux is right about me being exploring Perl. In fact, that is a good = exercice to play with regular expressions and data types as I had to = build a hash of hashes to do the thing. However, I wouldn't let a script in that stat if I knew of a = better/quicker/shorter method. I will then have to improve my script soon. What would be the best way to put values returned by the ps command you = just mentionned in variables? Thanks again for your great help.=20 P.S : I look like the typical lazy guy who don`t even read and try by = himself. This is because I am at work, ...

Re: Re: Re: Re: counting tr thinks it's modifying
I was talking about the behavior of the operator, not how it is implemented =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >De:Jarkko Hietaniemi <jhi@iki.fi> >Para:Daniel Ruoso <daniel@ruoso.com> >Assunto:Re: Re: Re: counting tr thinks it's modifying > >> so tr becomes a {if (r=3D=3Ds) {"COUNTING ONLY"} >else {"COUNTING AND REPLACEMENT"}} operator.=20 > >It's not like this is new behaviour: for example >5.004_05 has code >like this in doop.c: > > if (SvREADONLY(sv) && !(op->op_pri...

Re: Re: comments
below is the code in which the comments behave wierdly the code does not run properly with them else it is fine #!/usr/bin/perl # compiler directives use strict; use diagnostics; use Switch; use warnings; use Cwd; use vars; my $current_line; my $line_number=0; open (VERFILE,"<smaster.ver") || die "Unable to open/create smaster.ver.\n"; while(!eof(VERFILE)){ $current_line = &next_line(\*VERFILE); if($current_line =~ m/\Q*compare\E/i) { $line_number = &getLineNumber(\*VERFILE,"smaster.ver"); print "$line_...

Web resources about - Re: Re: - embarcadero.delphi.non-tech

Resources last updated: 12/16/2015 12:05:08 PM