gamedevlists-windows — List for discussing game development on the Windows platform

RE: [GD-Windows] GetAsyncKeyState / DI

[Pascal G. <pas...@ar...>]

I have implemented both as I use the events as a fall back for the case
where DI cannot be used. It's not that much difficult to add but at least
you get one safety net. Are you really adverse to using it because you can
pretty much reuse the code from the DI samples. I can't really say which one
is better though.

Pascal.

-----Original Message-----
From: Pierre Terdiman [mailto:p.t...@wa...]
Sent: 05 November 2002 12:14
To: gam...@li...
Subject: [GD-Windows] GetAsyncKeyState / DI


Say I have an app that just uses "simple" inputs :
- standard mouse messages
- GetAsyncKeyState() for keys

i.e. no special devices such as force feedback joysticks, etc (or even, no
joystick at all)

Is there any advantages to use DirectInput instead ? What would be the
benefits in my case ? (It looks to me like it wouldn't be better, but maybe
I'm misssing something)

Pierre

RE: [GD-Windows] GetAsyncKeyState / DI

[Gareth L. <GL...@cl...>]

DI can give you buffered input, which has it's benefits.

But DirectInput exists mainly for gamepads/joysticks/other input devices, so
that you can have your game treat all input in a consistant manner.

> -----Original Message-----
> From: Pierre Terdiman [mailto:p.t...@wa...]
> Sent: 05 November 2002 12:14
> To: gam...@li...
> Subject: [GD-Windows] GetAsyncKeyState / DI
> 
> 
> Say I have an app that just uses "simple" inputs :
> - standard mouse messages
> - GetAsyncKeyState() for keys
> 
> i.e. no special devices such as force feedback joysticks, etc 
> (or even, no
> joystick at all)
> 
> Is there any advantages to use DirectInput instead ? What would be the
> benefits in my case ? (It looks to me like it wouldn't be 
> better, but maybe
> I'm misssing something)
> 
> Pierre
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: See the NEW Palm 
> Tungsten T handheld. Power & Color in a compact size!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=555
> 

[GD-Windows] GetAsyncKeyState / DI

[Pierre T. <p.t...@wa...>]

Say I have an app that just uses "simple" inputs :
- standard mouse messages
- GetAsyncKeyState() for keys

i.e. no special devices such as force feedback joysticks, etc (or even, no
joystick at all)

Is there any advantages to use DirectInput instead ? What would be the
benefits in my case ? (It looks to me like it wouldn't be better, but maybe
I'm misssing something)

Pierre

RE: [GD-Windows] Strict ANSI and <windows.h>

[Grills, J. <jg...@so...>]

And there was much sadness.  Here's some code from STLPort, but the problem
is more generalized:  

template <class _Tp, class _Alloc >
void _Deque_base<_Tp,_Alloc>::_M_create_nodes(_Tp** __nstart, _Tp**
__nfinish)
{
  _Tp** __cur;
  _STLP_TRY {
    for (__cur = __nstart; __cur < __nfinish; ++__cur)
      *__cur = _M_map_size.allocate(this->buffer_size());
  }
  _STLP_UNWIND(_M_destroy_nodes(__nstart, __cur));
}

Because of the if() clause, the compiler doesn't know that __cur is always
going to be initialized in debug builds, and generates a warning on the last
line in the function.  So, it's not a perfect solution, but it still may be
better than not having it.  I'll have fix the errors as I come across them
and decide if it is worth it or not...

j

-----Original Message-----
From: Grills, Jeff 
Sent: Sunday, November 03, 2002 9:28 PM
To: 'Pierre Terdiman'; Grills, Jeff; 'Jon Watte';
gam...@li...
Subject: RE: [GD-Windows] Strict ANSI and <windows.h>



Excellent!  This works exactly as I desire.  No compile warnings, and in the
release build the disassembly doesn't show any sign of the if(False()){} at
all.  Time to go throw this in the header file that's always included,
rebuild, and see how it works for the whole project.

Thank you very much.

j

-----Original Message-----
From: Pierre Terdiman [mailto:p.t...@wa...]
Sent: Sunday, November 03, 2002 5:04 PM
To: Grills, Jeff; 'Jon Watte';
gam...@li...
Subject: Re: [GD-Windows] Strict ANSI and <windows.h>


> My complaint about this technique is that I then have to disable warning
> C4127: conditional expression is constant, something I'm not willing to
do.
> Anyone have a solution for that, but has no runtime impact?

Maybe something like this :

inline bool False(){ return false; }
#define for if(False()){} else for

You can also use a global extern variable instead of the inline function.
You can also use this in Debug builds only, if you fear it adds a "runtime
impact".

Pierre

RE: [GD-Windows] Strict ANSI and <windows.h>

[Grills, J. <jg...@so...>]

Excellent!  This works exactly as I desire.  No compile warnings, and in the
release build the disassembly doesn't show any sign of the if(False()){} at
all.  Time to go throw this in the header file that's always included,
rebuild, and see how it works for the whole project.

Thank you very much.

j

-----Original Message-----
From: Pierre Terdiman [mailto:p.t...@wa...]
Sent: Sunday, November 03, 2002 5:04 PM
To: Grills, Jeff; 'Jon Watte';
gam...@li...
Subject: Re: [GD-Windows] Strict ANSI and <windows.h>


> My complaint about this technique is that I then have to disable warning
> C4127: conditional expression is constant, something I'm not willing to
do.
> Anyone have a solution for that, but has no runtime impact?

Maybe something like this :

inline bool False(){ return false; }
#define for if(False()){} else for

You can also use a global extern variable instead of the inline function.
You can also use this in Debug builds only, if you fear it adds a "runtime
impact".

Pierre

Re: [GD-Windows] Strict ANSI and <windows.h>

[Kent Q. <ken...@co...>]

Sunday, November 3, 2002, 4:42:47 PM, gamedevlists-windows-admin wrote:
>     "Grills, Jeff" <jg...@so...>  writes:

>> Anyone have a solution for that, but has no runtime impact?

> Its only an issue when you reuse loop variables in multiple loops
> within the same scope.  For that situation I'm content to declare the
> loop variable in a separate statement right before the first loop that
> uses it.

Or you can simply invent a new loop variable each time. When we
realized this was going to be a problem with some code we were working
on, we just made a policy of trying to invent new variable names for
each loop. It handles the problem pretty neatly.

     Kent


-- 
Kent Quirk, CTO, CogniToy
ken...@co...
http://www.cognitoy.com

Re: [GD-Windows] Strict ANSI and <windows.h>

[Pierre T. <p.t...@wa...>]

> My complaint about this technique is that I then have to disable warning
> C4127: conditional expression is constant, something I'm not willing to
do.
> Anyone have a solution for that, but has no runtime impact?

Maybe something like this :

inline bool False(){ return false; }
#define for if(False()){} else for

You can also use a global extern variable instead of the inline function.
You can also use this in Debug builds only, if you fear it adds a "runtime
impact".

Pierre

RE: [GD-Windows] Strict ANSI and <windows.h>

[Grills, J. <jg...@so...>]

VS.net does indeed fix the problem.  We attempted to make the move to VS.net
a while ago, but due to issues with it, we had to abort and return to VC6.

Saying "don't do that" is not a good solution on a team of more than 10
programmers.  Verifying all projects build everywhere on all targets would
be too disruptive on programing workflow, since that would take a couple of
hours.

We've worked for 2+ years this way, it won't kill us to finish the project
like this.  I was just hoping for a magic solution.

j

-----Original Message-----
From: brian hook [mailto:bri...@py...]
Sent: Sunday, November 03, 2002 4:43 PM
To: gam...@li...
Subject: RE: [GD-Windows] Strict ANSI and <windows.h> 


> Our project builds under Linux using g++ and Windows using MSVC.

I had assumed this problem/lack-of-compliance was resolved with 
VS.Net?  Is that not the case or are you still using MSVC 6?

> It's fairly common for someone to check in code that builds in g++ 
> but fails to compile in MSVC due to this issue.

While I agree that a work around would be nice, the above is an 
indication of a discipline problem.  Establishing a policy of either:

A.) Verifying that, at the least, things build on all relevant target 
platforms before checking in 

or

B.) Stop declaring variables inside a for(..)

Doesn't seem like it should be that hard to do.

I basically do what Rich recommends, which is just declare loop 
variables once at their first use:

int i;

for ( i = 0; i < x; i++ ) { }

vs.

for ( int i = 0; i < x; x++ ) {}

I mean, switching to the latter shouldn't exactly cause people to 
suddenly become less efficient.  It took me a day to adjust.

> But I still don't want to disable that warning.  I guess I want 
> too much, oh well.

I'd be happy if <windows.h> was ANSI compliant. *sigh*

The way I fixed the problem was to create a "thunking" layer that 
resides in one file that is dependent on <windows.h>.  In this case, 
it's the <winsock2.h> that is the actual culprit.  Since a large chunk 
of WinSock is compatible with BSD sockets I had hoped to avoid creating 
excessive/overkill abstraction layers, but that doesn't seem to be the 
case, because the minute any file has to #include <winsock2.h> in order 
to get the definition of socket(), sendto() or structs like in_addr or 
sockaddr, that file can no longer be compiled as strict ANSI.

So now I basically I dispatch through intermediaries.  Blah.  But it's 
better than pulling out the prototypes from <winsock2.h>, de-
Windowsfying them (and hoping I don't screw it up), and then using them 
directly.

-Hook




-------------------------------------------------------
This SF.net email is sponsored by: ApacheCon, November 18-21 in
Las Vegas (supported by COMDEX), the only Apache event to be
fully supported by the ASF. http://www.apachecon.com
_______________________________________________
Gamedevlists-windows mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=555

RE: [GD-Windows] Strict ANSI and <windows.h>

[brian h. <bri...@py...>]

> Our project builds under Linux using g++ and Windows using MSVC.

I had assumed this problem/lack-of-compliance was resolved with 
VS.Net?  Is that not the case or are you still using MSVC 6?

> It's fairly common for someone to check in code that builds in g++ 
> but fails to compile in MSVC due to this issue.

While I agree that a work around would be nice, the above is an 
indication of a discipline problem.  Establishing a policy of either:

A.) Verifying that, at the least, things build on all relevant target 
platforms before checking in 

or

B.) Stop declaring variables inside a for(..)

Doesn't seem like it should be that hard to do.

I basically do what Rich recommends, which is just declare loop 
variables once at their first use:

int i;

for ( i = 0; i < x; i++ ) { }

vs.

for ( int i = 0; i < x; x++ ) {}

I mean, switching to the latter shouldn't exactly cause people to 
suddenly become less efficient.  It took me a day to adjust.

> But I still don't want to disable that warning.  I guess I want 
> too much, oh well.

I'd be happy if <windows.h> was ANSI compliant. *sigh*

The way I fixed the problem was to create a "thunking" layer that 
resides in one file that is dependent on <windows.h>.  In this case, 
it's the <winsock2.h> that is the actual culprit.  Since a large chunk 
of WinSock is compatible with BSD sockets I had hoped to avoid creating 
excessive/overkill abstraction layers, but that doesn't seem to be the 
case, because the minute any file has to #include <winsock2.h> in order 
to get the definition of socket(), sendto() or structs like in_addr or 
sockaddr, that file can no longer be compiled as strict ANSI.

So now I basically I dispatch through intermediaries.  Blah.  But it's 
better than pulling out the prototypes from <winsock2.h>, de-
Windowsfying them (and hoping I don't screw it up), and then using them 
directly.

-Hook

RE: [GD-Windows] Strict ANSI and <windows.h>

[Grills, J. <jg...@so...>]

Our project builds under Linux using g++ and Windows using MSVC.  It's
fairly common for someone to check in code that builds in g++ but fails to
compile in MSVC due to this issue.  But I still don't want to disable that
warning.  I guess I want too much, oh well.

j


-----Original Message-----
From: Rich [mailto:leg...@xm...]
Sent: Sunday, November 03, 2002 3:43 PM
To: gam...@li...
Subject: Re: [GD-Windows] Strict ANSI and <windows.h> 



In article
<9EA...@ma...>,
    "Grills, Jeff" <jg...@so...>  writes:

> Anyone have a solution for that, but has no runtime impact?

Its only an issue when you reuse loop variables in multiple loops
within the same scope.  For that situation I'm content to declare the
loop variable in a separate statement right before the first loop that
uses it.
-- 
Ask me about my upcoming book on Direct3D from Addison-Wesley!
  Direct3D Book <http://www.xmission.com/~legalize/book/>
    izfree: Open source tools for Windows Installer
            <http://izfree.sourceforge.net>


-------------------------------------------------------
This SF.net email is sponsored by: ApacheCon, November 18-21 in
Las Vegas (supported by COMDEX), the only Apache event to be
fully supported by the ASF. http://www.apachecon.com
_______________________________________________
Gamedevlists-windows mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=555

Re: [GD-Windows] Strict ANSI and <windows.h>

[Rich <leg...@xm...>]

In article <9EA...@ma...>,
    "Grills, Jeff" <jg...@so...>  writes:

> Anyone have a solution for that, but has no runtime impact?

Its only an issue when you reuse loop variables in multiple loops
within the same scope.  For that situation I'm content to declare the
loop variable in a separate statement right before the first loop that
uses it.
-- 
Ask me about my upcoming book on Direct3D from Addison-Wesley!
  Direct3D Book <http://www.xmission.com/~legalize/book/>
    izfree: Open source tools for Windows Installer
            <http://izfree.sourceforge.net>

RE: [GD-Windows] Strict ANSI and <windows.h>

[Grills, J. <jg...@so...>]

My complaint about this technique is that I then have to disable warning
C4127: conditional expression is constant, something I'm not willing to do.
Anyone have a solution for that, but has no runtime impact?

j

-----Original Message-----
From: Jon Watte [mailto:hp...@mi...]
Sent: Sunday, November 03, 2002 12:13 PM
To: gam...@li...
Subject: RE: [GD-Windows] Strict ANSI and <windows.h>



I'm following up directly to the list because I think the question 
is very valid and the reasons need to be re-inforced. Poorly designed 
macros can lead to debugging nightmares. Identity of the original 
requester hidden (as I'm forwarding a private e-mail).

1) The compiler will optimize out the if() for sure in release mode, 
and even usually in debug mode.

2) The extra else is so that you won't be caught in a dangling else 
problem. Consider:

  if( something )
    for( int i = 0; i < 3; ++i ) punt( i );
  else
    destroy_the_world();

Cheers,

			/ h+


> -----Original Message-----
> Sent: Friday, November 01, 2002 9:17 PM
> To: Jon Watte
> Subject: Re: [GD-Windows] Strict ANSI and <windows.h>
> 
> 
> > // work-around for brain-dead MSVC for scoping problem
> > #define for if(0);else for
> 
> I'm sure that there is a good reason for the else, but it isn't 
> clear to me
> why that would be any different from
> #define for if(1) for
> 
> Also, will the compiler optimize the extra if away, or will this 
> run slower?
> 
> 
> 


-------------------------------------------------------
This SF.net email is sponsored by: ApacheCon, November 18-21 in
Las Vegas (supported by COMDEX), the only Apache event to be
fully supported by the ASF. http://www.apachecon.com
_______________________________________________
Gamedevlists-windows mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=555

Re: [GD-Windows] Strict ANSI and <windows.h>

[Pierre T. <p.t...@wa...>]

Just in case..
http://www.flipcode.com/cgi-bin/msg.cgi?showThread=Tip-MSVCFor&forum=totd&id
=-1

> I'm following up directly to the list because I think the question
> is very valid and the reasons need to be re-inforced. Poorly designed
> macros can lead to debugging nightmares. Identity of the original
> requester hidden (as I'm forwarding a private e-mail).
>
> 1) The compiler will optimize out the if() for sure in release mode,
> and even usually in debug mode.
>
> 2) The extra else is so that you won't be caught in a dangling else
> problem. Consider:
>
>   if( something )
>     for( int i = 0; i < 3; ++i ) punt( i );
>   else
>     destroy_the_world();
>
> Cheers,
>
> / h+
>
>
> > -----Original Message-----
> > Sent: Friday, November 01, 2002 9:17 PM
> > To: Jon Watte
> > Subject: Re: [GD-Windows] Strict ANSI and <windows.h>
> >
> >
> > > // work-around for brain-dead MSVC for scoping problem
> > > #define for if(0);else for
> >
> > I'm sure that there is a good reason for the else, but it isn't
> > clear to me
> > why that would be any different from
> > #define for if(1) for
> >
> > Also, will the compiler optimize the extra if away, or will this
> > run slower?
> >
> >
> >
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: ApacheCon, November 18-21 in
> Las Vegas (supported by COMDEX), the only Apache event to be
> fully supported by the ASF. http://www.apachecon.com
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=555

RE: [GD-Windows] Strict ANSI and <windows.h>

[Jon W. <hp...@mi...>]

I'm following up directly to the list because I think the question 
is very valid and the reasons need to be re-inforced. Poorly designed 
macros can lead to debugging nightmares. Identity of the original 
requester hidden (as I'm forwarding a private e-mail).

1) The compiler will optimize out the if() for sure in release mode, 
and even usually in debug mode.

2) The extra else is so that you won't be caught in a dangling else 
problem. Consider:

  if( something )
    for( int i = 0; i < 3; ++i ) punt( i );
  else
    destroy_the_world();

Cheers,

			/ h+


> -----Original Message-----
> Sent: Friday, November 01, 2002 9:17 PM
> To: Jon Watte
> Subject: Re: [GD-Windows] Strict ANSI and <windows.h>
> 
> 
> > // work-around for brain-dead MSVC for scoping problem
> > #define for if(0);else for
> 
> I'm sure that there is a good reason for the else, but it isn't 
> clear to me
> why that would be any different from
> #define for if(1) for
> 
> Also, will the compiler optimize the extra if away, or will this 
> run slower?
> 
> 
> 

RE: [GD-Windows] Strict ANSI and <windows.h>

[Jon W. <hp...@mi...>]

The sucky part of MSVC version 6 (and the Microsoft headers) is that 
there's no way of getting BOTH conformant language AND <windows.h> at 
the same time.

If you're worrying about the for() scoping problem, then the work-around 
is to put this in some of your common headers (like StdAfx.h):

// work-around for brain-dead MSVC for scoping problem
#define for if(0);else for

Cheers,

				/ h+

> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Brian Hook
> Sent: Friday, November 01, 2002 1:24 PM
> To: gam...@li...
> Subject: [GD-Windows] Strict ANSI and <windows.h>
> 
> 
> I just tried compiling my project with strict ANSI (no language
> extensions) enabled in MSVC 6, and since it includes <windows.h> it
> barfs violently.
> 
> Is there a workaround for this by any chance?  I looked at #pragma and
> didn't see anything.
> 
> Brian
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: See the NEW Palm 
> Tungsten T handheld. Power & Color in a compact size!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=555
> 

[GD-Windows] Strict ANSI and <windows.h>

[Brian H. <bri...@py...>]

I just tried compiling my project with strict ANSI (no language
extensions) enabled in MSVC 6, and since it includes <windows.h> it
barfs violently.

Is there a workaround for this by any chance?  I looked at #pragma and
didn't see anything.

Brian

RE: [GD-Windows] Windows GUI grid control

[Jacob T. (C. D. Ltd) <Ja...@Co...>]

Thank you for all the suggestions did find some source code for good grid
apps but after looking at them, we have decided to use a tree control
because the tree control is a better match to the data we want to edit (and
we are much more experienced at using tree controls so it will be quicker to
use a tree control rather than learn about new things.  In this instance
time is more important than knowledge :-( ).

Jake

-----Original Message-----
From: Ivan-Assen Ivanov [mailto:as...@ha...]
Sent: 28 October 2002 12:54
To: GDWindows
Subject: Re: [GD-Windows] Windows GUI grid control


I would suggest taking a look at one of the many available
(often inexpensive) ActiveX grid controls. They are really easy
to use from VB, but using them from C++ is definitely possible
(just some annoying marshalling of parameters into Automation-
compliant types) - ATL is heavily recommended.

our VB guru recommends VSFlexGrid 7 or #Grid (nothing to do with C#).

regards,
Assen

----- Original Message ----- 
From: "Jacob Turner (Core Design Ltd)" <Ja...@Co...>
To: <gam...@li...>
Sent: Monday, October 28, 2002 2:33 PM
Subject: [GD-Windows] Windows GUI grid control


> Anybody got any pointers to a windows GUI grid control.
> 
> We want to have a grid display (e.g. like excel) 4 columns wide but
variable
> number of rows and each element of the grid is a drop-down list box (i.e.
> you can choose from a drop-down menu )
> 
> Apologies if the terminology is not correct but not sure what the names
are
> for the windows controls
> 
> Cheers
> 
> Jake
> 



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Gamedevlists-windows mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=555

Re: [GD-Windows] Choosing a folder with a dialog

[Laurent M. <lau...@fx...>]

> > Anybody knows which Win32 function to use (maybe MFC based) to allow
> > the user to select a folder not file ??
> > Using CFileDialog is fine for files but it only allows me to select a
> > folder that already contains a file. I'd like to be able to select
> > any folder. 
> 
> Here it is:
> 
> SHBrowseForFolder

I have been searching for a while in the MSDN, for a .NET equivalent.
It's weird, it does not seems implemented, so if you've got it :)

Laurent,

RE: [GD-Windows] Asian language support (IME)

[Daniel V. <vo...@ep...>]

I forgot a small snippet in my original email.

Before destroying your window you want to do something like below:

HIMC hImc = ImmGetContext( Window->hWnd );
if( hImc )
{
	ImmAssociateContext( Window->hWnd, NULL );
	ImmDestroyContext( hImc );
}

Thanks to Andy Glaister for pointing it out :)

-- Daniel, Epic Games Inc.

> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Daniel Vogel
> Sent: Friday, October 25, 2002 1:01 AM
> To: gam...@li...
> Subject: [GD-Windows] Asian language support (IME)
>
>
> As I couldn't find much useful documentation/ examples when I was looking
> for a way to add Asian language support to our input code I
> thought I should
> post what works for us now so other people might have it easier than I did
> :)
>
> The below snippet should work fine with Japanese, Chinese and
> Korean Windows
> (even Win98) though YMMV.
>
> BTW, as a little hint - make sure you have your Korean keyboard plugged in
> before installing Korean Windows if you don't speak the language as
> otherwise you won't be able to use the IME key... had to learn
> that the hard
> way ;)
>
>
> Some globals.
>
> INT	SupportsIME,
> 	CurrentIMESize;
>
>
> After creating the window.
>
> HIMC hImc = ImmGetContext( Window->hWnd );
> if( !hImc )
> {
> 	debugf(TEXT("Creating IME context."));
> 	hImc = ImmCreateContext();
> 	if( hImc )
> 		ImmAssociateContext( Window->hWnd, hImc );
> 	else
> 		debugf(TEXT("OS doesn't support IME."));
> }
> else
> 	ImmReleaseContext( Window->hWnd, hImc );
>
> SupportsIME = hImc != NULL;
>
>
>
> Once per frame (could possibly be done by handling some message
> but I didn't
> have time to look into this closer and hey, it works ;)).
>
> // IME stuff.
> if( SupportsIME )
> {
> 	HIMC hImc = ImmGetContext( Window->hWnd );
> 	if( !hImc )
> 	{
> 		debugf(TEXT("Creating IME context."));
> 		hImc = ImmCreateContext();
> 		if( hImc )
> 			ImmAssociateContext( Window->hWnd, hImc );
> 		else
> 			SupportsIME = 0;
>
> 		CurrentIMESize = 0;
> 	}
> 	else
> 		ImmReleaseContext( Window->hWnd, hImc );
> }
>
>
>
> Below is some code that handles the IME windows message.
>
>
> case WM_IME_COMPOSITION:
> {
> 	// Final composition string.
> 	if( lParam & GCS_RESULTSTR )
> 	{
> 		HIMC hImc = ImmGetContext(Window->hWnd);
>
> 		if( !hImc )
> 			appErrorf( TEXT("No IME context") );
>
> 		// Get the size of the result string.
> 		INT Size = ImmGetCompositionString( hImc,
> GCS_RESULTSTR, NULL, 0 );
>
> 		TCHAR* String = new TCHAR[Size+1];
> 		appMemzero( String, sizeof(TCHAR) * (Size+1) );
>
> 		// Get the result strings that is generated by IME.
> 		Size = ImmGetCompositionString( hImc,
> GCS_RESULTSTR, String, Size );
> 		Size /= sizeof( TCHAR );
>
> 		// Send backspaces.
> 		for( INT i=0; i<CurrentIMESize; i++ )
> 		{
> 			CauseInputEvent( IK_Backspace, IST_Press );
> 			CauseInputEvent( IK_Backspace, IST_Release );
> 		}
>
> 		// Send key to input system.
> 		for( INT i=0; i<Size; i++ )
> 		{
> 			INT Key = String[i];
> 			if( Key )
> 				Client->Engine->Key( this,
> IK_Unicode, String[i] );
> 		}
>
> 		delete [] String;
>
> 		ImmReleaseContext(Window->hWnd, hImc);
>
> 		CurrentIMESize = 0;
> 	}
> 	// Composition in progress.
> 	else if( lParam & GCS_COMPSTR )
> 	{
> 		HIMC hImc = ImmGetContext(Window->hWnd);
>
> 		if( !hImc )
> 			appErrorf( TEXT("No IME context") );
>
> 		// Get the size of the result string.
> 		INT Size = ImmGetCompositionString( hImc,
> GCS_COMPSTR, NULL, 0 );
>
> 		TCHAR* String = new TCHAR[Size+1];
> 		appMemzero( String, sizeof(TCHAR) * (Size+1) );
>
> 		// Get the result strings that is generated by IME.
> 		Size = ImmGetCompositionString( hImc, GCS_COMPSTR,
> String, Size );
> 		Size /= sizeof( TCHAR );
>
> 		// Send backspaces.
> 		for( INT i=0; i<CurrentIMESize; i++ )
> 		{
> 			CauseInputEvent( IK_Backspace, IST_Press );
> 			CauseInputEvent( IK_Backspace, IST_Release );
> 		}
>
> 		// Send key to input system
> 		for( INT i=0; i<Size; i++ )
> 		{
> 			INT Key = String[i];
> 			if( Key )
> 				Client->Engine->Key( this,
> IK_Unicode, String[i] );
> 		}
>
> 		delete [] String;
>
> 		ImmReleaseContext(Window->hWnd, hImc);
>
> 		CurrentIMESize = Size;
> 	}
> 	else
> 		return DefWindowProcX( Window->hWnd, iMessage,
> wParam, lParam );
>
> 	return 0;
> }
>
>
> You only want IME stuff for chatting and not for controlling the player so
> here's some code that toggles it on the fly.
>
> InParamter: bool Enable
>
> if( SupportsIME )
> {
> 	if( !Enable )
> 	{
> 		ImmAssociateContext( Window->hWnd, NULL );
> 		CurrentIMESize	= 0;
> 	}
> 	else
> 	{
> 		HIMC hImc = ImmGetContext( Window->hWnd );
> 		if( !hImc )
> 		{
> 			debugf(TEXT("Creating IME context."));
> 			hImc = ImmCreateContext();
> 			if( hImc )
> 				ImmAssociateContext( Window->hWnd, hImc );
> 			else
> 				SupportsIME = 0;
>
> 			CurrentIMESize	= 0;
> 		}
> 		else
> 		{
> 			ImmAssociateContext( Window->hWnd, hImc );
> 			ImmReleaseContext( Window->hWnd, hImc );
> 		}
> 	}
> }
>
>
> Hope this of help to someone out there :)
>
> -- Daniel, Epic Games Inc.
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: Influence the future
> of Java(TM) technology. Join the Java Community
> Process(SM) (JCP(SM)) program now.
> http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=555
>

Re: [GD-Windows] Windows GUI grid control

[Ivan-Assen I. <as...@ha...>]

I would suggest taking a look at one of the many available
(often inexpensive) ActiveX grid controls. They are really easy
to use from VB, but using them from C++ is definitely possible
(just some annoying marshalling of parameters into Automation-
compliant types) - ATL is heavily recommended.

our VB guru recommends VSFlexGrid 7 or #Grid (nothing to do with C#).

regards,
Assen

----- Original Message ----- 
From: "Jacob Turner (Core Design Ltd)" <Ja...@Co...>
To: <gam...@li...>
Sent: Monday, October 28, 2002 2:33 PM
Subject: [GD-Windows] Windows GUI grid control


> Anybody got any pointers to a windows GUI grid control.
> 
> We want to have a grid display (e.g. like excel) 4 columns wide but variable
> number of rows and each element of the grid is a drop-down list box (i.e.
> you can choose from a drop-down menu )
> 
> Apologies if the terminology is not correct but not sure what the names are
> for the windows controls
> 
> Cheers
> 
> Jake
> 

RE: [GD-Windows] Windows GUI grid control

[Andrew G. <ag...@cl...>]

You could do this by having a listview in report mode and implementing
custom behaviour for clicking on each row  where you create a temorary combo
box. I've done something similar before but with edit boxes for each item
and it wasn't much work. The listview also has an extended style flag that
will draw each element in a box for that grid look.

Failing that you can probably find an MFC class that already does this, Code
Guru (www.codeguru.com) is probably a good place to start looking. Even if
MFC isn't your thing it's usually trivial to convert a class back to Win32.


Andy @ 
Climax Brighton 



> -----Original Message-----
> From: Jacob Turner (Core Design Ltd) [mailto:Ja...@Co...]
> Sent: 28 October 2002 12:33
> To: gam...@li...
> Subject: [GD-Windows] Windows GUI grid control
> 
> 
> Anybody got any pointers to a windows GUI grid control.
> 
> We want to have a grid display (e.g. like excel) 4 columns 
> wide but variable
> number of rows and each element of the grid is a drop-down 
> list box (i.e.
> you can choose from a drop-down menu )
> 
> Apologies if the terminology is not correct but not sure what 
> the names are
> for the windows controls
> 
> Cheers
> 
> Jake
> 
> 

[GD-Windows] Windows GUI grid control

[Jacob T. (C. D. Ltd) <Ja...@Co...>]

Anybody got any pointers to a windows GUI grid control.

We want to have a grid display (e.g. like excel) 4 columns wide but variable
number of rows and each element of the grid is a drop-down list box (i.e.
you can choose from a drop-down menu )

Apologies if the terminology is not correct but not sure what the names are
for the windows controls

Cheers

Jake

Re: [GD-Windows] Asian language support (IME)

[jason z. <dir...@21...>]

Tm9wZS4NClNvbWUgSU1FcyBkbyBhdXRvbWF0aWMgY29tcGxldGlvbiB1c2luZyBjYW5kaWRhdGUg
bGlzdC4gQnV0IGl0IGlzIG5vdCBqdXN0IGNvbXBsZXRpb24sIA0Kc29tZXRpbWVzIGl0IG5lZWRz
IHRoZSB1c2VyIHRvIHNlbGVjdCBmcm9tIGNhbmRpZGF0ZSBsaXN0IGJ5IHByZXNzaW5nIG51bWJl
ciBrZXkuDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiRGFuaWVsIFZv
Z2VsIiA8dm9nZWxAZXBpY2dhbWVzLmNvbT4NClRvOiAiamFzb24gemhhbmciIDxkaXJlY3Rib3hA
MjFjbi5jb20+OyA8Z2FtZWRldmxpc3RzLXdpbmRvd3NAbGlzdHMuc291cmNlZm9yZ2UubmV0Pg0K
U2VudDogTW9uZGF5LCBPY3RvYmVyIDI4LCAyMDAyIDQ6NDggUE0NClN1YmplY3Q6IFJFOiBbR0Qt
V2luZG93c10gQXNpYW4gbGFuZ3VhZ2Ugc3VwcG9ydCAoSU1FKQ0KDQoNCj4gPiBJdCBzZWVtcyB5
b3UgZGlkbid0IGhhbmRsZSB0aGUgSU1FIGNhbmRpZGF0ZSBsaXN0LiBUaGVuIHRoZSB1c2VyDQo+
ID4gY2Fubm90IHNlbGVjdCBvbmUgZnJvbSBhIGZldyB3b3JkcyBvciBwaHJhc2VzIHdob3NlIGNv
bXBvc2l0aW9uDQo+ID4gc3RyaW5ncyBhcmUgdGhlIHNhbWUuDQo+IA0KPiBJcyB0aGUgY2FuZGlk
YXRlIGxpc3QgYSBmb3JtIG9mICJhdXRvbWF0aWMgY29tcGxldGlvbiI/IENhbiB5b3UgZW50ZXIg
ZXZlcnkNCj4gd29yZC8gcGhyYXNlIHdpdGhvdXQgdXNpbmcvIGltcGxlbWVudGluZyB0aGUgY2Fu
ZGlkYXRlIGxpc3Q/DQo+IA0KPiAtLSBEYW5pZWwsIEVwaWMgR2FtZXMgSW5jLg0KPiANCj4gDQo=

RE: [GD-Windows] Asian language support (IME)

[Daniel V. <vo...@ep...>]

> It seems you didn't handle the IME candidate list. Then the user
> cannot select one from a few words or phrases whose composition
> strings are the same.

Is the candidate list a form of "automatic completion"? Can you enter every
word/ phrase without using/ implementing the candidate list?

-- Daniel, Epic Games Inc.

Re: [GD-Windows] Asian language support (IME)

[jason z. <dir...@21...>]

SXQgc2VlbXMgeW91IGRpZG4ndCBoYW5kbGUgdGhlIElNRSBjYW5kaWRhdGUgbGlzdC4gVGhlbiB0
aGUgdXNlciBjYW5ub3Qgc2VsZWN0IG9uZQ0KZnJvbSBhIGZldyB3b3JkcyBvciBwaHJhc2VzIHdo
b3NlIGNvbXBvc2l0aW9uIHN0cmluZ3MgYXJlIHRoZSBzYW1lLg0KLS0tLS0gT3JpZ2luYWwgTWVz
c2FnZSAtLS0tLSANCkZyb206ICJEYW5pZWwgVm9nZWwiIDx2b2dlbEBlcGljZ2FtZXMuY29tPg0K
VG86IDxnYW1lZGV2bGlzdHMtd2luZG93c0BsaXN0cy5zb3VyY2Vmb3JnZS5uZXQ+DQpTZW50OiBG
cmlkYXksIE9jdG9iZXIgMjUsIDIwMDIgMTowMSBQTQ0KU3ViamVjdDogW0dELVdpbmRvd3NdIEFz
aWFuIGxhbmd1YWdlIHN1cHBvcnQgKElNRSkNCg0KDQo+IEFzIEkgY291bGRuJ3QgZmluZCBtdWNo
IHVzZWZ1bCBkb2N1bWVudGF0aW9uLyBleGFtcGxlcyB3aGVuIEkgd2FzIGxvb2tpbmcNCj4gZm9y
IGEgd2F5IHRvIGFkZCBBc2lhbiBsYW5ndWFnZSBzdXBwb3J0IHRvIG91ciBpbnB1dCBjb2RlIEkg
dGhvdWdodCBJIHNob3VsZA0KPiBwb3N0IHdoYXQgd29ya3MgZm9yIHVzIG5vdyBzbyBvdGhlciBw
ZW9wbGUgbWlnaHQgaGF2ZSBpdCBlYXNpZXIgdGhhbiBJIGRpZA0KPiA6KQ0KPiANCj4gVGhlIGJl
bG93IHNuaXBwZXQgc2hvdWxkIHdvcmsgZmluZSB3aXRoIEphcGFuZXNlLCBDaGluZXNlIGFuZCBL
b3JlYW4gV2luZG93cw0KPiAoZXZlbiBXaW45OCkgdGhvdWdoIFlNTVYuDQo+IA0KPiBCVFcsIGFz
IGEgbGl0dGxlIGhpbnQgLSBtYWtlIHN1cmUgeW91IGhhdmUgeW91ciBLb3JlYW4ga2V5Ym9hcmQg
cGx1Z2dlZCBpbg0KPiBiZWZvcmUgaW5zdGFsbGluZyBLb3JlYW4gV2luZG93cyBpZiB5b3UgZG9u
J3Qgc3BlYWsgdGhlIGxhbmd1YWdlIGFzDQo+IG90aGVyd2lzZSB5b3Ugd29uJ3QgYmUgYWJsZSB0
byB1c2UgdGhlIElNRSBrZXkuLi4gaGFkIHRvIGxlYXJuIHRoYXQgdGhlIGhhcmQNCj4gd2F5IDsp
DQo+IA0KPiANCj4gU29tZSBnbG9iYWxzLg0KPiANCj4gSU5UIFN1cHBvcnRzSU1FLA0KPiBDdXJy
ZW50SU1FU2l6ZTsNCj4gDQo+IA0KPiBBZnRlciBjcmVhdGluZyB0aGUgd2luZG93Lg0KPiANCj4g
SElNQyBoSW1jID0gSW1tR2V0Q29udGV4dCggV2luZG93LT5oV25kICk7DQo+IGlmKCAhaEltYyAp
DQo+IHsNCj4gZGVidWdmKFRFWFQoIkNyZWF0aW5nIElNRSBjb250ZXh0LiIpKTsNCj4gaEltYyA9
IEltbUNyZWF0ZUNvbnRleHQoKTsNCj4gaWYoIGhJbWMgKQ0KPiBJbW1Bc3NvY2lhdGVDb250ZXh0
KCBXaW5kb3ctPmhXbmQsIGhJbWMgKTsNCj4gZWxzZQ0KPiBkZWJ1Z2YoVEVYVCgiT1MgZG9lc24n
dCBzdXBwb3J0IElNRS4iKSk7DQo+IH0NCj4gZWxzZQ0KPiBJbW1SZWxlYXNlQ29udGV4dCggV2lu
ZG93LT5oV25kLCBoSW1jICk7DQo+IA0KPiBTdXBwb3J0c0lNRSA9IGhJbWMgIT0gTlVMTDsNCj4g
DQo+IA0KPiANCj4gT25jZSBwZXIgZnJhbWUgKGNvdWxkIHBvc3NpYmx5IGJlIGRvbmUgYnkgaGFu
ZGxpbmcgc29tZSBtZXNzYWdlIGJ1dCBJIGRpZG4ndA0KPiBoYXZlIHRpbWUgdG8gbG9vayBpbnRv
IHRoaXMgY2xvc2VyIGFuZCBoZXksIGl0IHdvcmtzIDspKS4NCj4gDQo+IC8vIElNRSBzdHVmZi4N
Cj4gaWYoIFN1cHBvcnRzSU1FICkNCj4gew0KPiBISU1DIGhJbWMgPSBJbW1HZXRDb250ZXh0KCBX
aW5kb3ctPmhXbmQgKTsNCj4gaWYoICFoSW1jICkNCj4gew0KPiBkZWJ1Z2YoVEVYVCgiQ3JlYXRp
bmcgSU1FIGNvbnRleHQuIikpOw0KPiBoSW1jID0gSW1tQ3JlYXRlQ29udGV4dCgpOw0KPiBpZigg
aEltYyApDQo+IEltbUFzc29jaWF0ZUNvbnRleHQoIFdpbmRvdy0+aFduZCwgaEltYyApOw0KPiBl
bHNlDQo+IFN1cHBvcnRzSU1FID0gMDsNCj4gDQo+IEN1cnJlbnRJTUVTaXplID0gMDsNCj4gfQ0K
PiBlbHNlDQo+IEltbVJlbGVhc2VDb250ZXh0KCBXaW5kb3ctPmhXbmQsIGhJbWMgKTsNCj4gfQ0K
PiANCj4gDQo+IA0KPiBCZWxvdyBpcyBzb21lIGNvZGUgdGhhdCBoYW5kbGVzIHRoZSBJTUUgd2lu
ZG93cyBtZXNzYWdlLg0KPiANCj4gDQo+IGNhc2UgV01fSU1FX0NPTVBPU0lUSU9OOg0KPiB7DQo+
IC8vIEZpbmFsIGNvbXBvc2l0aW9uIHN0cmluZy4NCj4gaWYoIGxQYXJhbSAmIEdDU19SRVNVTFRT
VFIgKQ0KPiB7DQo+IEhJTUMgaEltYyA9IEltbUdldENvbnRleHQoV2luZG93LT5oV25kKTsNCj4g
DQo+IGlmKCAhaEltYyApDQo+IGFwcEVycm9yZiggVEVYVCgiTm8gSU1FIGNvbnRleHQiKSApOw0K
PiANCj4gLy8gR2V0IHRoZSBzaXplIG9mIHRoZSByZXN1bHQgc3RyaW5nLg0KPiBJTlQgU2l6ZSA9
IEltbUdldENvbXBvc2l0aW9uU3RyaW5nKCBoSW1jLCBHQ1NfUkVTVUxUU1RSLCBOVUxMLCAwICk7
DQo+IA0KPiBUQ0hBUiogU3RyaW5nID0gbmV3IFRDSEFSW1NpemUrMV07DQo+IGFwcE1lbXplcm8o
IFN0cmluZywgc2l6ZW9mKFRDSEFSKSAqIChTaXplKzEpICk7DQo+IA0KPiAvLyBHZXQgdGhlIHJl
c3VsdCBzdHJpbmdzIHRoYXQgaXMgZ2VuZXJhdGVkIGJ5IElNRS4NCj4gU2l6ZSA9IEltbUdldENv
bXBvc2l0aW9uU3RyaW5nKCBoSW1jLCBHQ1NfUkVTVUxUU1RSLCBTdHJpbmcsIFNpemUgKTsNCj4g
U2l6ZSAvPSBzaXplb2YoIFRDSEFSICk7DQo+IA0KPiAvLyBTZW5kIGJhY2tzcGFjZXMuDQo+IGZv
ciggSU5UIGk9MDsgaTxDdXJyZW50SU1FU2l6ZTsgaSsrICkNCj4gew0KPiBDYXVzZUlucHV0RXZl
bnQoIElLX0JhY2tzcGFjZSwgSVNUX1ByZXNzICk7DQo+IENhdXNlSW5wdXRFdmVudCggSUtfQmFj
a3NwYWNlLCBJU1RfUmVsZWFzZSApOw0KPiB9DQo+IA0KPiAvLyBTZW5kIGtleSB0byBpbnB1dCBz
eXN0ZW0uDQo+IGZvciggSU5UIGk9MDsgaTxTaXplOyBpKysgKQ0KPiB7DQo+IElOVCBLZXkgPSBT
dHJpbmdbaV07DQo+IGlmKCBLZXkgKQ0KPiBDbGllbnQtPkVuZ2luZS0+S2V5KCB0aGlzLCBJS19V
bmljb2RlLCBTdHJpbmdbaV0gKTsNCj4gfQ0KPiANCj4gZGVsZXRlIFtdIFN0cmluZzsNCj4gDQo+
IEltbVJlbGVhc2VDb250ZXh0KFdpbmRvdy0+aFduZCwgaEltYyk7DQo+IA0KPiBDdXJyZW50SU1F
U2l6ZSA9IDA7DQo+IH0NCj4gLy8gQ29tcG9zaXRpb24gaW4gcHJvZ3Jlc3MuDQo+IGVsc2UgaWYo
IGxQYXJhbSAmIEdDU19DT01QU1RSICkNCj4gew0KPiBISU1DIGhJbWMgPSBJbW1HZXRDb250ZXh0
KFdpbmRvdy0+aFduZCk7DQo+IA0KPiBpZiggIWhJbWMgKQ0KPiBhcHBFcnJvcmYoIFRFWFQoIk5v
IElNRSBjb250ZXh0IikgKTsNCj4gDQo+IC8vIEdldCB0aGUgc2l6ZSBvZiB0aGUgcmVzdWx0IHN0
cmluZy4NCj4gSU5UIFNpemUgPSBJbW1HZXRDb21wb3NpdGlvblN0cmluZyggaEltYywgR0NTX0NP
TVBTVFIsIE5VTEwsIDAgKTsNCj4gDQo+IFRDSEFSKiBTdHJpbmcgPSBuZXcgVENIQVJbU2l6ZSsx
XTsNCj4gYXBwTWVtemVybyggU3RyaW5nLCBzaXplb2YoVENIQVIpICogKFNpemUrMSkgKTsNCj4g
DQo+IC8vIEdldCB0aGUgcmVzdWx0IHN0cmluZ3MgdGhhdCBpcyBnZW5lcmF0ZWQgYnkgSU1FLg0K
PiBTaXplID0gSW1tR2V0Q29tcG9zaXRpb25TdHJpbmcoIGhJbWMsIEdDU19DT01QU1RSLCBTdHJp
bmcsIFNpemUgKTsNCj4gU2l6ZSAvPSBzaXplb2YoIFRDSEFSICk7DQo+IA0KPiAvLyBTZW5kIGJh
Y2tzcGFjZXMuDQo+IGZvciggSU5UIGk9MDsgaTxDdXJyZW50SU1FU2l6ZTsgaSsrICkNCj4gew0K
PiBDYXVzZUlucHV0RXZlbnQoIElLX0JhY2tzcGFjZSwgSVNUX1ByZXNzICk7DQo+IENhdXNlSW5w
dXRFdmVudCggSUtfQmFja3NwYWNlLCBJU1RfUmVsZWFzZSApOw0KPiB9DQo+IA0KPiAvLyBTZW5k
IGtleSB0byBpbnB1dCBzeXN0ZW0NCj4gZm9yKCBJTlQgaT0wOyBpPFNpemU7IGkrKyApDQo+IHsN
Cj4gSU5UIEtleSA9IFN0cmluZ1tpXTsNCj4gaWYoIEtleSApDQo+IENsaWVudC0+RW5naW5lLT5L
ZXkoIHRoaXMsIElLX1VuaWNvZGUsIFN0cmluZ1tpXSApOw0KPiB9DQo+IA0KPiBkZWxldGUgW10g
U3RyaW5nOw0KPiANCj4gSW1tUmVsZWFzZUNvbnRleHQoV2luZG93LT5oV25kLCBoSW1jKTsNCj4g
DQo+IEN1cnJlbnRJTUVTaXplID0gU2l6ZTsNCj4gfQ0KPiBlbHNlDQo+IHJldHVybiBEZWZXaW5k
b3dQcm9jWCggV2luZG93LT5oV25kLCBpTWVzc2FnZSwgd1BhcmFtLCBsUGFyYW0gKTsNCj4gDQo+
IHJldHVybiAwOw0KPiB9DQo+IA0KPiANCj4gWW91IG9ubHkgd2FudCBJTUUgc3R1ZmYgZm9yIGNo
YXR0aW5nIGFuZCBub3QgZm9yIGNvbnRyb2xsaW5nIHRoZSBwbGF5ZXIgc28NCj4gaGVyZSdzIHNv
bWUgY29kZSB0aGF0IHRvZ2dsZXMgaXQgb24gdGhlIGZseS4NCj4gDQo+IEluUGFyYW10ZXI6IGJv
b2wgRW5hYmxlDQo+IA0KPiBpZiggU3VwcG9ydHNJTUUgKQ0KPiB7DQo+IGlmKCAhRW5hYmxlICkN
Cj4gew0KPiBJbW1Bc3NvY2lhdGVDb250ZXh0KCBXaW5kb3ctPmhXbmQsIE5VTEwgKTsNCj4gQ3Vy
cmVudElNRVNpemUgPSAwOw0KPiB9DQo+IGVsc2UNCj4gew0KPiBISU1DIGhJbWMgPSBJbW1HZXRD
b250ZXh0KCBXaW5kb3ctPmhXbmQgKTsNCj4gaWYoICFoSW1jICkNCj4gew0KPiBkZWJ1Z2YoVEVY
VCgiQ3JlYXRpbmcgSU1FIGNvbnRleHQuIikpOw0KPiBoSW1jID0gSW1tQ3JlYXRlQ29udGV4dCgp
Ow0KPiBpZiggaEltYyApDQo+IEltbUFzc29jaWF0ZUNvbnRleHQoIFdpbmRvdy0+aFduZCwgaElt
YyApOw0KPiBlbHNlDQo+IFN1cHBvcnRzSU1FID0gMDsNCj4gDQo+IEN1cnJlbnRJTUVTaXplID0g
MDsNCj4gfQ0KPiBlbHNlDQo+IHsNCj4gSW1tQXNzb2NpYXRlQ29udGV4dCggV2luZG93LT5oV25k
LCBoSW1jICk7DQo+IEltbVJlbGVhc2VDb250ZXh0KCBXaW5kb3ctPmhXbmQsIGhJbWMgKTsNCj4g
fQ0KPiB9DQo+IH0NCj4gDQo+IA0KPiBIb3BlIHRoaXMgb2YgaGVscCB0byBzb21lb25lIG91dCB0
aGVyZSA6KQ0KPiANCj4gLS0gRGFuaWVsLCBFcGljIEdhbWVzIEluYy4NCj4gDQo+IA0KPiANCj4g
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K
PiBUaGlzIHNmLm5ldCBlbWFpbCBpcyBzcG9uc29yZWQgYnk6IEluZmx1ZW5jZSB0aGUgZnV0dXJl
IA0KPiBvZiBKYXZhKFRNKSB0ZWNobm9sb2d5LiBKb2luIHRoZSBKYXZhIENvbW11bml0eSANCj4g
UHJvY2VzcyhTTSkgKEpDUChTTSkpIHByb2dyYW0gbm93LiANCj4gaHR0cDovL2Fkcy5zb3VyY2Vm
b3JnZS5uZXQvY2dpLWJpbi9yZWRpcmVjdC5wbD9zdW5tMDAwNGVuDQo+IF9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEdhbWVkZXZsaXN0cy13aW5kb3dz
IG1haWxpbmcgbGlzdA0KPiBHYW1lZGV2bGlzdHMtd2luZG93c0BsaXN0cy5zb3VyY2Vmb3JnZS5u
ZXQNCj4gaHR0cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vZ2FtZWRl
dmxpc3RzLXdpbmRvd3MNCj4gQXJjaGl2ZXM6DQo+IGh0dHA6Ly9zb3VyY2Vmb3JnZS5uZXQvbWFp
bGFyY2hpdmUvZm9ydW0ucGhwP2ZvcnVtX2lkPTU1NQ0KPiANCj4gDQo=