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

Re: [GD-Windows] More timer fun! (sorry for revisit!)

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

> Thus, the best implementation of reading
> the time stamp counter is this:
>
> inline uint64 read_tsc()
> {
>   __asm {
>     rdtsc
>   }
> }

Actually the best implementation is to insert a cpuid instruction before
rdtsc, to prevent out-of-sequence execution from ruining the results.

For more details, please refer to Intel's application notes "Using the RDTSC
instruction for performance monitoring".

Pierre

RE: [GD-Windows] More timer fun! (sorry for revisit!)

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

First, a suggestion for your suggested inline assembly:
If you let the compiler generate the prolog and epilog, it can
inline the function. Thus, the best implementation of reading
the time stamp counter is this:

inline uint64 read_tsc()
{
  __asm {
    rdtsc
  }
}

The RDTSC instruction luckily uses the defined calling convention
for returning 64-bit integers (in EDX:EAX).


Second, the archives contains my long rant on the subject of
timers on PC hardware. To re-cap:

On PC hardware, there's basically three timers that are generally
available.

1) the "tick" counter. This is a millisecond-type timer, and is
   read by calls such as timeGetTime() or GetTickCount(). It is
   driven by the age-old ISA interrupt controller (which by now
   is probably virtualized into some do-everything-legacy chip
   three bridges away from the CPU on the motherboard).
   This is sort-of millisecond precise. Reading it requires a
   bus transaction all the way out to the LPC ISA interface, so
   it's fairly slow as such things go (say, 1-2 microseconds).
   (boo!) If there's heavy bus traffic, such as running a game
   which makes good use of AGP and DMA for graphics and audio,
   this timer will glitch and lose a tick or two every so often;
   slowly falling behind. (boo!)

2) the "performance" counter. This is a microsecond-type timer,
   and is read by the QueryPerformanceCounter() call. It
   typically advances by little over 1 million ticks per second,
   or little over 3 million ticks per second, depending on bus.
   It is derived from, I think, some PCI controller counter.
   Reading it requires, at least, a CPU->northbridge bus
   transaction, and as such is not super snappy. Call it 1
   microsecond. (boo!)
   If there's heavy bus traffic, on many, common chip sets, even
   very new ones, this timer may suddenly jump between one and
   four seconds forward in time (boo!). I believe there is some
   internal race WRT this counter being 64 bits, but kept in two
   separate 32-bit registers, but don't hold me to that.

3) the "time stamp" counter. This is a register internal to the
   CPU, which counts, using a 64 bit timer, the number of CPU
   clocks executed since system power-on (more or less). On a
   four GHz machine, it will take over a hundred and thirty years
   for this counter to wrap (yay!). Reading this counter stays
   within the CPU, and as such is really fast (call it 40 cycles)
   (yay!). Because it really measures CPU clock ticks on all but
   the most exotic architectures (read: Transmeta :-), this
   counter is extremely useful for determining exactly how long a
   piece of code takes to execute, on a micro-benchmarking scale.
   You still have to compensate for the fact that you may take an
   interrupt in the middle of measurement, so run the same piece
   of code 100 times and pick the BEST value -- that's how well
   your code can perform, which is what you want to measure unless
   you're trying to model starting with cold caches. (yay!)

   Unfortunately, this third model, if you want to turn it into
   real time, needs the relation between CPU ticks and seconds.
   This can be had by profiling the CPU on start-up, using some of
   the other timers available. Such profiling always has a little
   bit of imprecision (boo!). What's worse, on laptops, the rate
   of advance on this register will fluctuate wildly, because, you
   guessed it, the CPU speed fluctuates wildly. (boo!)


Thus, there is no fool-proof way of measuring elapsed time on a PC
in a really accurate manner. If you're trying to keep a simulation
in sync over a network, say, this may be of high importance to you
so you'll probably, in the end, come up with some system which
uses a combination of all three. I use the cycle counter for most
measurements, because it's fast and cheap, and then I continually
re-calibrate by using the other two counters and having them vote.
If they vote differently, I discard that sample and wait until
later. This seems to work reasonably well.

On the CPU-speed-switching machines, you are mostly toast. The best
you can do is selectively instantiate another class for your clock,
and hope that the effect of jumping timer inaccuracy won't totally
kill your application.

Cheers,

			/ h+


> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Josiah Manson
> Sent: Monday, December 23, 2002 9:27 PM
> To: gam...@li...
> Subject: Re: [GD-Windows] More timer fun! (sorry for revisit!)
>
>
> I don't know if you are going to think this is a good idea or not, but if
> you want a really high accuracy timer, it may be possible to get
> the number
> of actual CPU clock cycles elapsed and use that as your measurement. Of
> course this means that you have to use 64 bit integers, pay
> attention to the
> clock wrapping over, and limiting yourself to pentiums and
> higher, but that
> is a small price to pay. I think that it also won't work with laptops.
>
> The idea is pretty simple though. First get a reading of clock cycles, use
> the good old C time() function in a buisy loop for a second, then get
> another reading of clock cycles at your programs startup. The
> difference in
> clock cycles is the frequency of the cpu.
>
> Now, if you find any number of elapsed cycles, and divide by the
> frequency,
> you know how much time has passed to a high degree of accuracy.
> Lets see if
> I can dig out some code here. The following 2 code snippets
> should work, but
> the first is probably better. I got it out of a simple profiler I made
> recently.
>
> // 64 bit... yum
> _declspec(naked) __int64 _fastcall _profileTick()
> {
>  _asm rdtsc
>  _asm ret
> }
>
> // clock is 32 bit integer
> // this is a pentium specific macro that will count cpu cycles
> #define clocktick(clock) _asm push eax\
>                         _asm push edx\
>                         _asm rdtsc\
>                         _asm mov clock, eax\
>                         _asm pop edx\
>                         _asm pop eax
>
>
>
> -------------------------------------------------------
> 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] More timer fun! (sorry for revisit!)

[Josiah M. <jm...@ma...>]

I don't know if you are going to think this is a good idea or not, but if
you want a really high accuracy timer, it may be possible to get the number
of actual CPU clock cycles elapsed and use that as your measurement. Of
course this means that you have to use 64 bit integers, pay attention to the
clock wrapping over, and limiting yourself to pentiums and higher, but that
is a small price to pay. I think that it also won't work with laptops.

The idea is pretty simple though. First get a reading of clock cycles, use
the good old C time() function in a buisy loop for a second, then get
another reading of clock cycles at your programs startup. The difference in
clock cycles is the frequency of the cpu.

Now, if you find any number of elapsed cycles, and divide by the frequency,
you know how much time has passed to a high degree of accuracy. Lets see if
I can dig out some code here. The following 2 code snippets should work, but
the first is probably better. I got it out of a simple profiler I made
recently.

// 64 bit... yum
_declspec(naked) __int64 _fastcall _profileTick()
{
 _asm rdtsc
 _asm ret
}

// clock is 32 bit integer
// this is a pentium specific macro that will count cpu cycles
#define clocktick(clock) _asm push eax\
                        _asm push edx\
                        _asm rdtsc\
                        _asm mov clock, eax\
                        _asm pop edx\
                        _asm pop eax

Re: [GD-Windows] More timer fun! (sorry for revisit!)

[Lachlan L. <da_...@ho...>]

    Hey all,

    The (admittedly hobby) project I am currently working on requires that a
reliable measure of time can be assumed (for interpolating between starting
and ending times for events). From the discussion on this list it seems like
there isn't an absolutely *infallible* way of accomplishing this feat. Each
method of timing had its own problems and so using any one seemed to doom my
app to the timebomb of "when will my timer jump/drift and add
inaccuracies?". The idea I'm throwing around at the moment is to use (on
every frame update) both QPC and timeGetTime(). I'd use QPC in general and
measure the delta from the last measurement. If the delta was above a
certain error value I'd check it against the timeGetTime() one. If the same
(or similar) delta occurs in the timeGetTime delta, I could assume that the
large delta was a result of a lock-up of some sort and trust the QPC value.
If timeGetTime doesn't give a similar delta to QPC then I'd assume it was
one of the lovely "quantum" leaps and use the timeGetTime measurement for
this frame's time.

    My question is: can I assume that timeGetTime won't suffer from the
quantum leap at the same time as the QPC (Ie, that they aren't linked)? Or
at least that the percentage of times that BOTH the QPC and timeGetTime
suffer from this leap is so low that the possibility is worth ignoring?

    Cheers,

    - Lachlan

-----Original Message-----
From: Jon Watte [mailto:hp...@mi...]
Sent: Monday, September 02, 2002 3:31 PM
To: Grills, Jeff; gam...@li...
Subject: RE: [GD-Windows] More timer fun!


> don't manifest on their development machines.  Even Tom Forsyth, whom
most
> of us would say is a reasonably intelligent programmer, had problems
with
> clock drift on non-development machines using timeGetTime().  Can
> we expect
> as much from your average run of the mill programmer?  I think not.

But now we're dealing with TIME!

There's no way for your app to tell whether QueryPerformanceCounter()
jumped forward, or whether some device driver decided to lock up the
machine for a second. There is NO DIFFERENCE at the application
programming level. Thus, these functions aren't broken (unless they
actually GO BACKWARDS, as opposed to just lagging or skipping).

Note that two computers that are not hooked up to the same physical
crystal are doomed to skew out of sync sooner or later. The description
I saw from Tom sounds to me as if there was no attempt to bring the
clocks back in sync over the network. If you don't do that, you will
lose, always. Just like a digital mixing studio (or video production
studio) Just Won't Work (tm) without a common house clock.

> MS is in the unique position to know enough about the actual hardware
to
> understand if the system has these problems with QPC, and avoid the
extra

I believe chip set vendors write drivers for their chip sets, just
like toaster vendors write drivers for their toasters. And, looking
at the varying quality of chipset drivers (and other drivers in
general), I've seen little correlation between "more compled systems"
and "more competent driver writers".

Cheers,

/ h+



-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
Gamedevlists-windows mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=555


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=urceforge1&refcode1=3390
_______________________________________________
Gamedevlists-windows mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_idU5

Re: [GD-Windows] GetDeviceGammaRamp() is lieing to me

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

Have you contacted the IHV that provided your driver?  It sounds like
a driver bug to me.  Not many apps get/set the gamma ramp and I have
encountered bugs in D3D gamma support myself.
-- 
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] GetDeviceGammaRamp() is lieing to me

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

I previously asked:

>  WORD userRamp[ 768 ];
>  HDC dc = CreateDC( "DISPLAY", 0, 0, 0 );
>  GetDeviceGammaRamp( dc, userRamp );
>  /* I'm not getting the actual ramp in effect here, but 
>   * instead some Ersatz default ramp. */


Could it be that graphics cards somehow recognize our app as a 
"game" and purposefully lie to us about the current gamma 
settings, such that they can apply a special "game gamma" setting? 
If so, why does the operation of restoring the gamma (using data 
we initially read) go through to set the ramp (which is darker) and 
leave it like that when we quit? (we do restore in an atexit() 
handler).

Cheers,

			/ h+

RE: [GD-Windows] GetDeviceGammaRamp() is lieing to me

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

I'm running Windows XP, although I'm hearing complaints from people 
on Windows 2k as well (and they're using nVIDIA hardware; I'm using 
ATI).

Cheers,

				/ h+

> Which operating system?

> > If I go into my display control panel settings and crank the 
> > gamma way up (both "game gamma" and "desktop gamma"), then 
> > starting my program will still retrieve the same "default" gamma 
> > ramp, apply its ramp (which is dimmer), and on shutdown, set the 
> > screen to a very dim setting.

Re: [GD-Windows] GetDeviceGammaRamp() is lieing to me

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

Which operating system?

> In my program, I call GetDeviceGammaRamp() to read the user's 
> active gamma settings. Then, if there's not "sufficient" gamma 
> adjustment, I set my own gamma ramp with SetDeviceGammaRamp(). 
> When the program exits, I restore the ramp I read back from 
> GetDeviceGammaRamp() on start-up.
> 
> Unfortunately, it appears that the device is lieing to me. I 
> get the data as such:
> 
>   WORD userRamp[ 768 ];
>   HDC dc = CreateDC( "DISPLAY", 0, 0, 0 );
>   GetDeviceGammaRamp( dc, userRamp );
> 
> What ends up happening is that I always get back some "default" 
> gamma ramp with a little bit of compensation; I apply my own 
> ramp, and then on shutdown I set the ramp "back" to some very 
> low gamma setting.
> 
> If I go into my display control panel settings and crank the 
> gamma way up (both "game gamma" and "desktop gamma"), then 
> starting my program will still retrieve the same "default" gamma 
> ramp, apply its ramp (which is dimmer), and on shutdown, set the 
> screen to a very dim setting.
> 
> This is on a Radeon 9700, though I've heard similar problems 
> from users with nVIDIA hardware as well.
> 
> What's going on?
> 
>                     / h+

Re: [GD-Windows] GetDeviceGammaRamp() is lieing to me

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

Which operating system?

> In my program, I call GetDeviceGammaRamp() to read the user's 
> active gamma settings. Then, if there's not "sufficient" gamma 
> adjustment, I set my own gamma ramp with SetDeviceGammaRamp(). 
> When the program exits, I restore the ramp I read back from 
> GetDeviceGammaRamp() on start-up.
> 
> Unfortunately, it appears that the device is lieing to me. I 
> get the data as such:
> 
>   WORD userRamp[ 768 ];
>   HDC dc = CreateDC( "DISPLAY", 0, 0, 0 );
>   GetDeviceGammaRamp( dc, userRamp );
> 
> What ends up happening is that I always get back some "default" 
> gamma ramp with a little bit of compensation; I apply my own 
> ramp, and then on shutdown I set the ramp "back" to some very 
> low gamma setting.
> 
> If I go into my display control panel settings and crank the 
> gamma way up (both "game gamma" and "desktop gamma"), then 
> starting my program will still retrieve the same "default" gamma 
> ramp, apply its ramp (which is dimmer), and on shutdown, set the 
> screen to a very dim setting.
> 
> This is on a Radeon 9700, though I've heard similar problems 
> from users with nVIDIA hardware as well.
> 
> What's going on?
> 
>                     / h+

[GD-Windows] GetDeviceGammaRamp() is lieing to me

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

In my program, I call GetDeviceGammaRamp() to read the user's 
active gamma settings. Then, if there's not "sufficient" gamma 
adjustment, I set my own gamma ramp with SetDeviceGammaRamp(). 
When the program exits, I restore the ramp I read back from 
GetDeviceGammaRamp() on start-up.

Unfortunately, it appears that the device is lieing to me. I 
get the data as such:

  WORD userRamp[ 768 ];
  HDC dc = CreateDC( "DISPLAY", 0, 0, 0 );
  GetDeviceGammaRamp( dc, userRamp );

What ends up happening is that I always get back some "default" 
gamma ramp with a little bit of compensation; I apply my own 
ramp, and then on shutdown I set the ramp "back" to some very 
low gamma setting.

If I go into my display control panel settings and crank the 
gamma way up (both "game gamma" and "desktop gamma"), then 
starting my program will still retrieve the same "default" gamma 
ramp, apply its ramp (which is dimmer), and on shutdown, set the 
screen to a very dim setting.

This is on a Radeon 9700, though I've heard similar problems 
from users with nVIDIA hardware as well.

What's going on?

                    / h+


--
  If you believe you can succeed
  Or if you believe you cannot
  You are right.

RE: [GD-Windows] Disabling ALT in Windows

[Matt N. <mat...@ni...>]

Never mind, I've figured it out now :-) If anyone's interested, you need =
to handle the WM_SYSKEYDOWN and WM_SYSKEYUP messages and return 0 if =
wParam =3D=3D VK_MENU.

Matt.

> -----Original Message-----
> From: Matt Newport=20
> Sent: 02 December 2002 17:02
> To: gam...@li...
> Subject: [GD-Windows] Disabling ALT in Windows
>=20
>=20
> I'm sure this is somewhere obvious in MSDN but I can't find=20
> it at the moment... I want to stop Windows switching to the=20
> menu in my app when ALT is pressed. I imagine I have to=20
> intercept some message to stop it happening. Can anyone point=20
> me in the right direction?
>=20
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.423 / Virus Database: 238 - Release Date: 25/11/2002
> =20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: Get the new Palm Tungsten T=20
> handheld. Power & Color in a compact size!=20
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
> _______________________________________________
> Gamedevlists-windows mailing list=20
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives: http://sourceforge.net/mailarchive/forum.php?forum_idU5
>=20
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.423 / Virus Database: 238 - Release Date: 25/11/2002
> =20
>=20

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.423 / Virus Database: 238 - Release Date: 25/11/2002
=20

[GD-Windows] Disabling ALT in Windows

[Matt N. <mat...@ni...>]

I'm sure this is somewhere obvious in MSDN but I can't find it at the =
moment... I want to stop Windows switching to the menu in my app when =
ALT is pressed. I imagine I have to intercept some message to stop it =
happening. Can anyone point me in the right direction?

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.423 / Virus Database: 238 - Release Date: 25/11/2002
=20

[GD-Windows] UNSUBSCRIBE

[Marek R. <mar...@st...>]

> I think Outlook may be using OLE/COM drag-and-drop data interchange,
> which is rather nastier (as far as I can find) than the regular file-
> and-message-based drag-and-drop that I'm sure you're using now.

> I just did a search again, and searching for IDropTarget and
> RegisterDragDrop seems to be the start of the documentation yarn ball
> for this topic.

> Cheers,

>                         / h+

>> -----Original Message-----
>> From: gam...@li...
>> [mailto:gam...@li...]On Behalf Of
>> Pierre Terdiman
>> Sent: Thursday, November 28, 2002 1:39 PM
>> To: gam...@li...
>> Subject: [GD-Windows] Drag and drop from Outlook Express
>>
>>
>> I'd like to be able to drag-and-drop mails from Outlook Express directly
>> into my app. I've already implemented drag-and-drop from files to
>> a running
>> app in the past, it worked fine. But I'm not sure how to do that
>> with mails
>> from Outlook.
>>
>> When I drag a mail from Outlook to, say the Windows desktop,
>> cursor changes
>> to the little "+" indicating drop is possible. Then a file is created, say
>> Mail.eml.
>>
>> However, if I drag that same mail over my app (which otherwise supports
>> drag-and-drop of other files), the cursor doesn't change and nothing
>> happens.
>>
>> So I guess there's something missing to enable that kind of interaction.
>> Ideally I'd like to get back the eml file(s) directly into my
>> app, even if I
>> have to create them myself from whatever I get from Outlook when the drop
>> occurs...
>>
>> Ideas ?
>>
>> Cheers :)
>> Pierre
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: Get the new Palm Tungsten T
>> handheld. Power & Color in a compact size!
>> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
>> _______________________________________________
>> Gamedevlists-windows mailing list
>> Gam...@li...
>> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
>> Archives:
>> http://sourceforge.net/mailarchive/forum.php?forum_id=555
>>



> -------------------------------------------------------
> This SF.net email is sponsored by: Get the new Palm Tungsten T 
> handheld. Power & Color in a compact size! 
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
> _______________________________________________
> 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] Drag and drop from Outlook Express

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

I think Outlook may be using OLE/COM drag-and-drop data interchange,
which is rather nastier (as far as I can find) than the regular file-
and-message-based drag-and-drop that I'm sure you're using now.

I just did a search again, and searching for IDropTarget and
RegisterDragDrop seems to be the start of the documentation yarn ball
for this topic.

Cheers,

			/ h+

> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Pierre Terdiman
> Sent: Thursday, November 28, 2002 1:39 PM
> To: gam...@li...
> Subject: [GD-Windows] Drag and drop from Outlook Express
>
>
> I'd like to be able to drag-and-drop mails from Outlook Express directly
> into my app. I've already implemented drag-and-drop from files to
> a running
> app in the past, it worked fine. But I'm not sure how to do that
> with mails
> from Outlook.
>
> When I drag a mail from Outlook to, say the Windows desktop,
> cursor changes
> to the little "+" indicating drop is possible. Then a file is created, say
> Mail.eml.
>
> However, if I drag that same mail over my app (which otherwise supports
> drag-and-drop of other files), the cursor doesn't change and nothing
> happens.
>
> So I guess there's something missing to enable that kind of interaction.
> Ideally I'd like to get back the eml file(s) directly into my
> app, even if I
> have to create them myself from whatever I get from Outlook when the drop
> occurs...
>
> Ideas ?
>
> Cheers :)
> Pierre
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Get the new Palm Tungsten T
> handheld. Power & Color in a compact size!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
> _______________________________________________
> 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] Drag and drop from Outlook Express

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

You should write a simple application that dumps all the
available Clipboard formats that are carried with the drag'n'drop
(drag'n'drop functionality is very similar to Clipboard cut'n'paste).

Examine them and you'll probably find one that suits you.

Oh, and RTFMSDN too :-)

Regards,
Assen

----- Original Message ----- 
From: "Pierre Terdiman" <p.t...@wa...>
To: <gam...@li...>
Sent: Thursday, November 28, 2002 11:39 PM
Subject: [GD-Windows] Drag and drop from Outlook Express


> I'd like to be able to drag-and-drop mails from Outlook Express directly
> into my app. I've already implemented drag-and-drop from files to a running
> app in the past, it worked fine. But I'm not sure how to do that with mails
> from Outlook.
> 
> When I drag a mail from Outlook to, say the Windows desktop, cursor changes
> to the little "+" indicating drop is possible. Then a file is created, say
> Mail.eml.
> 
> However, if I drag that same mail over my app (which otherwise supports
> drag-and-drop of other files), the cursor doesn't change and nothing
> happens.
> 
> So I guess there's something missing to enable that kind of interaction.
> Ideally I'd like to get back the eml file(s) directly into my app, even if I
> have to create them myself from whatever I get from Outlook when the drop
> occurs...
> 
> Ideas ?
> 
> Cheers :)
> Pierre
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Get the new Palm Tungsten T 
> handheld. Power & Color in a compact size! 
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
> _______________________________________________
> 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] Drag and drop from Outlook Express

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

I'd like to be able to drag-and-drop mails from Outlook Express directly
into my app. I've already implemented drag-and-drop from files to a running
app in the past, it worked fine. But I'm not sure how to do that with mails
from Outlook.

When I drag a mail from Outlook to, say the Windows desktop, cursor changes
to the little "+" indicating drop is possible. Then a file is created, say
Mail.eml.

However, if I drag that same mail over my app (which otherwise supports
drag-and-drop of other files), the cursor doesn't change and nothing
happens.

So I guess there's something missing to enable that kind of interaction.
Ideally I'd like to get back the eml file(s) directly into my app, even if I
have to create them myself from whatever I get from Outlook when the drop
occurs...

Ideas ?

Cheers :)
Pierre

Re: [GD-Windows] MS Platform SDK for IA64

[Eero P. <epa...@ko...>]

brian hook wrote:

> >The platform SDK update site:
> >http://www.microsoft.com/msdownload/platformsdk/sdkupdate/
>
>
> Baffling, bloody fricking baffling.  I spent at least 15 minutes on the
> site trying various permutations of searches, and that URL never came
> up. *sigh*
>
> Anyway, thanks, that _seems_ to be what I need, but I'm not sure what
> the "Windows XP SP1" bit means -- is it a part of XP SP1, or does it
> require it, or what?


It seems possible to install the SDK even on Win98 (Don't ask me
why I know), but I think it did want WinXP as the platform,
but I may remember this incorrectly (NT might also be ok here)



		Eero

Re: [GD-Windows] MS Platform SDK for IA64

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

> The platform SDK update site:
> http://www.microsoft.com/msdownload/platformsdk/sdkupdate/

Baffling, bloody fricking baffling.  I spent at least 15 minutes on the 
site trying various permutations of searches, and that URL never came 
up. *sigh*

Anyway, thanks, that _seems_ to be what I need, but I'm not sure what 
the "Windows XP SP1" bit means -- is it a part of XP SP1, or does it 
require it, or what?

> (This reply is late, because my ISP has changed its name, and the
> list admin decided to not accept this message for that reason.
> Thanks, admin ;-)

He's a right bastard, that one. =)

Brian

Re: [GD-Windows] MS Platform SDK for IA64

[Eero P. <epa...@ko...>]

Brian Hook wrote:

 > I've searched all over the MSDN site, and so far I can only see the MS
 > Platform SDK for IA64 available via CD for a token amount of money
 > (<$10).  In the past they've also made it available for download -- does
 > anyone know if it is?  I've searched all over and can't find it, and the
 > last time I went ahead and ordered a CD for an SDK from them (PPC2002
 > SDK) I found the link the next day =|
 >

The platform SDK update site:
http://www.microsoft.com/msdownload/platformsdk/sdkupdate/
offers
: Core SDK (Windows XP SP1)
: 189.5 MB / Download Time: 7 hr 41 min / Updated: August 2002
:  (Build 5.2.3672.1) Read This First
:  Build environment (25 MB) - Installed
:  Documentation (release and prerelease) (89.5 MB) - Installed
:  Sample and source code (10.5 MB) - Installed
:  Build environment (64-bit) (63.4 MB)
:

Is the last component what you need?


			Eero

(This reply is late, because my ISP has changed its name, and the
list admin decided to not accept this message for that reason.
Thanks, admin ;-)
I had the unsubscribe/resubscribe)

[GD-Windows] MS Platform SDK for IA64

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

I've searched all over the MSDN site, and so far I can only see the MS
Platform SDK for IA64 available via CD for a token amount of money
(<$10).  In the past they've also made it available for download -- does
anyone know if it is?  I've searched all over and can't find it, and the
last time I went ahead and ordered a CD for an SDK from them (PPC2002
SDK) I found the link the next day =|

Brian

RE: [GD-Windows] Unicode editboxes

[Phil T. <ph...@mi...>]

To add automatic Unicode support to Win98 you need the unicows.dll.
Here is the MSDN article on how to use it:

http://msdn.microsoft.com/library/default.asp?url=3D/library/en-us/win9x/=
u
nilayer_4e05.asp

Here is the link to get the redist for the library:

http://www.microsoft.com/downloads/release.asp?releaseid=3D30039


-----Original Message-----
From: Wayne Coles [mailto:wc...@re...]=20
Sent: Friday, November 08, 2002 1:49 AM
To: 'gam...@li...'
Subject: RE: [GD-Windows] Unicode editboxes

> I read in the msdn that regular Editboxes support both ANSI and
Unicode
> text. Great news, but unfortunately, that was all I could find...

If you write an application with Unicode defined, the window will be
Unicode, if not the window will be ANSI.

If you want to create a Unicode window whilst building without Unicode
defined then that's where you find the SDK has been a bit 'sly' :)

CreateWindowEx is actually a macro rather than a function call. In ANSI
builds it expands to the function call CreateWindowExA, in Unicode
builds it
expands to CreateWindowExW. So you can bypass this by calling
CreateWindowExW directly (only CreateWindowEx is documented, I've never
found the others in the documentation). Anyway, for all normal purposes
you
shouldn't need to worry about it. In Unicode builds it 'just works' :)

FWIW CreateWindow is also a macro that expands to CreateWindowEx, which
is
irritating if you happen to be implementing a class\interface that you
want
to include a 'CreateWindow' method (currently I've opted for
'OpenWindow'
;).

You can find out if a window is Unicode or not by calling
'IsWindowUnicode(
HWND hWnd )'.

> How are unicode editboxes created and handled? Do they work in Win98?
> Where
> can I find more info about this?

AFAIK win98 needs a Unicode library, but I don't know what it is or
where
you get it as I haven't been on or targeted win98 for a long time, sorry
:(

Wayne
-Virus scanned and cleared ok


-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm=20
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=3D555

RE: [GD-Windows] Unicode editboxes

[Wayne C. <wc...@re...>]

> I read in the msdn that regular Editboxes support both ANSI and Unicode
> text. Great news, but unfortunately, that was all I could find...

If you write an application with Unicode defined, the window will be
Unicode, if not the window will be ANSI.

If you want to create a Unicode window whilst building without Unicode
defined then that's where you find the SDK has been a bit 'sly' :)

CreateWindowEx is actually a macro rather than a function call. In ANSI
builds it expands to the function call CreateWindowExA, in Unicode builds it
expands to CreateWindowExW. So you can bypass this by calling
CreateWindowExW directly (only CreateWindowEx is documented, I've never
found the others in the documentation). Anyway, for all normal purposes you
shouldn't need to worry about it. In Unicode builds it 'just works' :)

FWIW CreateWindow is also a macro that expands to CreateWindowEx, which is
irritating if you happen to be implementing a class\interface that you want
to include a 'CreateWindow' method (currently I've opted for 'OpenWindow'
;).

You can find out if a window is Unicode or not by calling 'IsWindowUnicode(
HWND hWnd )'.

> How are unicode editboxes created and handled? Do they work in Win98?
> Where
> can I find more info about this?

AFAIK win98 needs a Unicode library, but I don't know what it is or where
you get it as I haven't been on or targeted win98 for a long time, sorry :(

Wayne
-Virus scanned and cleared ok

[GD-Windows] Unicode editboxes

[Javier A. <ja...@py...>]

I read in the msdn that regular Editboxes support both ANSI and Unicode
text. Great news, but unfortunately, that was all I could find...

How are unicode editboxes created and handled? Do they work in Win98? Where
can I find more info about this?

  Javier Arevalo
  Pyro Studios

[GD-Windows] Admin: Reply To Change

[Tom H. <to...@3d...>]

Hi again folks!

As of this email, we're changing over the following mailing lists to 
reply-to-list:

gdalgorithms
gd-consoles
gd-design
gd-general
gd-linux
gd-windows

A vote was conducted on the algorithms list since that has the highest 
number of subscribers (~2000) and most of the people on the other lists are 
also on the algorithms list. Of the responses I got, 30 wanted us to change 
and 4 wanted us to stay the way we were. I haven't gotten another vote for 
10 hours, so I figure that's probably all the votes we're going to get.


Thanks for your time!

Tom

Re: [GD-Windows] memory leak?

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

RnJvbSB3aW5kb3dzIHRhc2sgbWFuYWdlci4NCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0t
LSANCkZyb206ICJDb2xpbiBGYWhleSIgPGNwZmFoZXlAZWFydGhsaW5rLm5ldD4NClRvOiAiR0RX
aW5kb3dzIiA8Z2FtZWRldmxpc3RzLXdpbmRvd3NAbGlzdHMuc291cmNlZm9yZ2UubmV0Pg0KU2Vu
dDogRnJpZGF5LCBOb3ZlbWJlciAwOCwgMjAwMiA5OjQ3IEFNDQpTdWJqZWN0OiBSZTogW0dELVdp
bmRvd3NdIG1lbW9yeSBsZWFrPw0KDQoNCj4gMjAwMiBOb3ZlbWJlciA3dGgNCj4gVGh1cnNkYXkN
Cj4gDQo+IEphc29uLA0KPiANCj4gICBPa2F5LCBzbyBob3cgRElEIHlvdSBnZXQgdGhlICJwcm9j
ZXNzIG1lbW9yeSBjb25zdW1wdGlvbiINCj4gdmFsdWVzIHRoYXQgeW91IHJlcG9ydGVkIGluIHlv
dXIgQy1zdHlsZSBjb21tZW50cz8NCj4gDQo+IC0tLSBDb2xpbg0KPiBjcGZhaGV5QGVhcnRobGlu
ay5uZXQNCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBUaGlzIHNmLm5ldCBlbWFpbCBpcyBz
cG9uc29yZWQgYnk6IFNlZSB0aGUgTkVXIFBhbG0gDQo+IFR1bmdzdGVuIFQgaGFuZGhlbGQuIFBv
d2VyICYgQ29sb3IgaW4gYSBjb21wYWN0IHNpemUhDQo+IGh0dHA6Ly9hZHMuc291cmNlZm9yZ2Uu
bmV0L2NnaS1iaW4vcmVkaXJlY3QucGw/cGFsbTAwMDFlbg0KPiBfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBHYW1lZGV2bGlzdHMtd2luZG93cyBtYWls
aW5nIGxpc3QNCj4gR2FtZWRldmxpc3RzLXdpbmRvd3NAbGlzdHMuc291cmNlZm9yZ2UubmV0DQo+
IGh0dHBzOi8vbGlzdHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL2dhbWVkZXZsaXN0
cy13aW5kb3dzDQo+IEFyY2hpdmVzOg0KPiBodHRwOi8vc291cmNlZm9yZ2UubmV0L21haWxhcmNo
aXZlL2ZvcnVtLnBocD9mb3J1bV9pZD01NTUNCj4gDQo+IA0K