gamedevlists-windows Mailing List for gamedev (Page 37)
Brought to you by:
vexxed72
You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(48) |
Oct
(58) |
Nov
(49) |
Dec
(38) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(124) |
Feb
(83) |
Mar
(17) |
Apr
(37) |
May
(12) |
Jun
(20) |
Jul
(47) |
Aug
(74) |
Sep
(62) |
Oct
(72) |
Nov
(54) |
Dec
(13) |
2003 |
Jan
(36) |
Feb
(8) |
Mar
(38) |
Apr
(3) |
May
(6) |
Jun
(133) |
Jul
(20) |
Aug
(18) |
Sep
(12) |
Oct
(4) |
Nov
(28) |
Dec
(36) |
2004 |
Jan
(22) |
Feb
(51) |
Mar
(28) |
Apr
(9) |
May
(20) |
Jun
(9) |
Jul
(37) |
Aug
(20) |
Sep
(23) |
Oct
(15) |
Nov
(23) |
Dec
(27) |
2005 |
Jan
(22) |
Feb
(20) |
Mar
(5) |
Apr
(14) |
May
(10) |
Jun
|
Jul
(6) |
Aug
(6) |
Sep
|
Oct
(12) |
Nov
(1) |
Dec
|
2006 |
Jan
(18) |
Feb
(4) |
Mar
(3) |
Apr
(6) |
May
(4) |
Jun
(3) |
Jul
(16) |
Aug
(40) |
Sep
(6) |
Oct
(1) |
Nov
|
Dec
(2) |
2007 |
Jan
(5) |
Feb
(2) |
Mar
(4) |
Apr
(1) |
May
(13) |
Jun
|
Jul
(26) |
Aug
(3) |
Sep
(10) |
Oct
|
Nov
(4) |
Dec
(5) |
2008 |
Jan
(1) |
Feb
|
Mar
(4) |
Apr
|
May
|
Jun
(5) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Pierre T. <p.t...@wa...> - 2002-12-24 06:09:41
|
> 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 |
From: Jon W. <hp...@mi...> - 2002-12-24 05:48:44
|
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 > |
From: Josiah M. <jm...@ma...> - 2002-12-24 03:27:26
|
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 |
From: Lachlan L. <da_...@ho...> - 2002-12-23 05:33:09
|
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 |
From: Rich <leg...@xm...> - 2002-12-06 20:34:08
|
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> |
From: Jon W. <hp...@mi...> - 2002-12-06 19:29:04
|
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+ |
From: Jon W. <hp...@mi...> - 2002-12-04 17:20:16
|
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. |
From: brian h. <bri...@py...> - 2002-12-04 03:03:32
|
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+ |
From: brian h. <bri...@py...> - 2002-12-04 03:03:32
|
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+ |
From: Jon W. <hp...@mi...> - 2002-12-04 02:17:16
|
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. |
From: Matt N. <mat...@ni...> - 2002-12-02 19:04:03
|
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 |
From: Matt N. <mat...@ni...> - 2002-12-02 16:58:14
|
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 |
From: Marek R. <mar...@st...> - 2002-11-29 20:30:17
|
> 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 |
From: Jon W. <hp...@mi...> - 2002-11-29 18:55:13
|
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 > |
From: Ivan-Assen I. <as...@ha...> - 2002-11-28 21:49:36
|
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 |
From: Pierre T. <p.t...@wa...> - 2002-11-28 21:41:09
|
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 |
From: Eero P. <epa...@ko...> - 2002-11-09 10:17:38
|
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 |
From: brian h. <bri...@py...> - 2002-11-09 09:21:35
|
> 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 |
From: Eero P. <epa...@ko...> - 2002-11-09 06:53:03
|
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) |
From: Brian H. <bri...@py...> - 2002-11-08 21:47:52
|
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 |
From: Phil T. <ph...@mi...> - 2002-11-08 10:11:36
|
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 |
From: Wayne C. <wc...@re...> - 2002-11-08 09:54:03
|
> 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 |
From: Javier A. <ja...@py...> - 2002-11-08 09:09:08
|
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 |
From: Tom H. <to...@3d...> - 2002-11-08 03:58:08
|
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 |
From: jason z. <dir...@21...> - 2002-11-08 02:31:39
|
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 |