|
LPCVOID lpBaseAddress
DWORD RealStart
DWORD FakeStart
can u please show me an example code as that would be very helpful.
Thanks
|
|
|
|
|
Ok it looks like you're adding/subtracting the VALUE of RealStart/FakeStart, not the address,
right?
lpBaseAddress = (LPCVOID)(((BYTE*)lpBaseAddress - RealStart) + FakeStart);
Subtracting the ADDRESS of RealStart then adding the ADDRESS of FakeStart doesn't make sense
to me so I assume that's what you're doing.
Is that what you had in mind?
Mark
|
|
|
|
|
thanks a lot m8 that worked 
|
|
|
|
|
Hello everyone!
I was just wondering this... I have a variable that I want to write to a file that can have only 4 values, so only 2 bits needed... If I can't write plain 2 bits to a file, what's the most "efficient" thing I can use? char?
Thanks! (and sorry if I'm being teh big n00b...  )
Windows Calculator told me I will die at 28. 
|
|
|
|
|
A single byte is the smallest size you can write to disk.
"Alot of the people on this forum are incredibly stupid, thinking that the internet is real"
Score: 1.0 in the Soap Box
|
|
|
|
|
|
The smallest unit you can write is a WORD (32 bits is the most common WORD size, nowadays). However, if you wrote just a WORD to a hard drive that writes 4K sized blocks, you will have a lot of unutilized space.
|
|
|
|
|
You're thinking of a "CPU word" which is the size of the CPU's integer registers (32 or 64 bits on modern desktop CPUs).
The C/C++ type WORD is always two bytes.
|
|
|
|
|
I guess I am mixing up my words! 
Thanks,
Geo
|
|
|
|
|
|
it will write 2 bytes but the minimum block for a file could be 4k or more depending upon how the harddisk was formated, i.e. fat16, fat32, NTFS, etc
-Prakash
|
|
|
|
|
Now THAT explains why Windows Explorer says a file is 211B but it says "Size on Disk: 4,00KB"... You learn something new everyday.  Thanks!
Windows Calculator told me I will die at 28.
|
|
|
|
|
Lord Kixdemp wrote: Now THAT explains why Windows Explorer says a file is 211B but it says "Size on Disk: 4,00KB".
exactly .
-Prakash
|
|
|
|
|
Just for clarification, under Windows a WORD is 16 bits, or two bytes. A DWORD is 32 bits, or four bytes.
Software Zen: delete this;
|
|
|
|
|
Hmmm! A WORD to the wise. I think our answers to the posted question is a BIT much.
|
|
|
|
|
Hopefully someone can give me some pointer on how to deal with the following scenario:
I have a project that will be given to 3 clients. Although the core code (about 80%) is the same, some dialogs/resources are different for each client. Should I finish for a client first, then create 2 copies of the project folder and change 20% of each code to accomodate the other 2? This will mean the core 80% is duplicated 3 times, and whenever I fix something, I need to do it 3 times.
Is there a way to do all 3 projects in one folder, sharing the core 80%, but appears as 3 separate projects (3 .dsw's/dsp's) and hopefully 3 projects in SourceSafe?
I would really appreciate it if someone can help me here. Thanks a bunch.
|
|
|
|
|
You could have 3 projects in one solution.
Keep all the common code together in one folder. The 3 projects will all use the same common
code. I keep common code in a separate folder on disk as well as separate folder in the
projects. Files unique to each project (dialog-related/resource files in your case) go to the
usual "Source Files" and "Header Files" project folders.
Mark
|
|
|
|
|
How do I separate the dialogs, aren't they listed together (resource.h and .rc)?
|
|
|
|
|
It sounds like resources are the main thing you need to keep separate (well, with their
associated dialog window code).
Resource files can have #include statements too, so you can have common resources and individual
custom resources.
Mark
|
|
|
|
|
Well you could use a Source Control product like Visual Source Safe to "share" files in as many projects as you like.
led mike
|
|
|
|
|
Will you know at runtime which client is which?
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Depending on what is different between the 3, you could always write your code such that the interfaces are the same for all of them and you use some configuration setting to determine which implementation gets created during runtime.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
You can build this all into a single project, and then compile it differently for each client. The approach I've used in the past is something like this:
#define CUSTOMER_ALPHA 0
#define CUSTOMER_BETA 1
#define CUSTOMER_GAMMA 2
#define CUSTOMER CUSTOMER_BETA
class MyDialog : public CDialog {
#if CUSTOMER == CUSTOMER_ALPHA
enum { IDD = IDD_CUSTOMER_ALPHA };
#elif CUSTOMER == CUSTOMER_BETA
enum { IDD = IDD_CUSTOMER_BETA };
#elif CUSTOMER == CUSTOMER_GAMMA
enum { IDD = IDD_CUSTOMER_GAMMA };
#endif
};You create separate resources for the dialog for each customer: IDD_CUSTOMER_ALPHA, IDD_CUSTOMER_BETA, and IDD_CUSTOMER_GAMMA. I'm assuming here that the dialogs for each of the customers are similar enough that you can use a single class to support all three. Within the MyDialog code you can look at the CUSTOMER value in case there are differences you need to know about.
Software Zen: delete this;
|
|
|
|
|
Greetings everyone,
I'm working on a screensaver that I'd like to use GDI+ with (to display alpha-blended images, etc). What I'm trying to accomplish is to paint the desktop with background images, so to handle this I'm calling EnumDisplayMonitors from within my message pump (in the WM_PAINT case).
I'm correctly getting the callback against my MonitorDisplayProc, and since I bracket the EnumDisplayMonitors call with GetDC(null), ReleaseDC(null, hdc), I'm able to pass the DC that (should) correspond to the virtual desktop to EnumDisplayMonitors.
Inside of MonitorDisplayProc, I'm able to take the provided hdcMonitor and lprcMonitor vars and paint to the relevant display via FillRect(hdcMonitor, lprcMonitor, (HBRUSH) GetStockObject(BLACK|GRAY|WHITE_BRUSH)). So far, so good.
Now, when I use the hdcMonitor object to create a GDI+ Graphics object, it seems to work okay for the primary monitor. I can load an Image from disk and draw to the primary screen just fine.
However, when my MonitorDisplayProc gets the callback for my second display, graphics.GetVisibleClipBounds(&clipRect) is returning a {0,0,0,0} rect. Appropriately, graphics.isVisible(...) is also failing.
Reading the MSDN docs for GetVisibleClipBounds makes me believe something in the hdcMonitor object is incorrect, but I'm having a hard time proving it - I'm trying to fetch the hdcMonitor's bounding box via GetRandomRgn(hdcMonitor, hRgn, SYSRGN) but that is returning 0's when I pass it into region.GetBounds(...). This makes me think I'm misunderstanding something about graphics's world/page/device conversion, but I'm not sure.
There's lots of documentation on the web about C# using forms, but I'm having a rough time finding anything that directly references this problem either via Google or MSDN.
Does anybody out there have any idea why Gdiplus::Graphics would be reading a HDC 'improperly' as specified above? Any help would be *greatly* appreciated.
|
|
|
|
|
Hi, I am trying to write a fullscreen game... and I have a question about the message loop
I am curently using the following form:
<br />
while(msg.message!=WM_QUIT)<br />
if(PeekMessage(&msg,0,0,0,PM_REMOVE)){<br />
TranslateMessage(&msg);<br />
DispatchMessage(&msg);<br />
}<br />
else Render();<br />
whitch ain't so bad for the momment, but in future it's gonna have multiplayer
and user input,and other stuff.I saw in Quake3's source the loop was way diffrent.
And now the question:
Can anyone(hwo had previously worked whit somethings like that ...hopefully)give me an ideea
about how the message loop should be like.
Thnaks
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
