WalderMort wrote: Any suggestions? Why, yes: don't use macros, they make your code unreadable ;p No, seriously: using macros is dangerous, with very few exceptions. Regarding your example, your choice of symbol alone already breaks two common safeguards against macro problems: 1. Do not ever use a symbol with starting '_'! This is what the system libraries use internaly to prevent name clashes with any symbols the programmer may define! The problem with name clashes and macros is that macros clash silently, and may break system libraries, resulting in very hard to trace runtime errors (or compiler error,s, if you're lucky) 2. Use capital letters for symbols denoting const or #define symbols. This, also, has to do with preventing name clashes. It may seem overkill, but better be safe than sorry. I've spent many, many weeks hunting down errors caused my macro name clashes caused by other people's code (and in some cases even by MS #defines!). Do yourself (and everyone else) a favor and don't add to that misery!

Chuck O'Toole wrote: Theory goes that the EndPaint() call will take care of the ValidateRect() on the .rcPaint member of the PAINTSTRUCT you received in BeginPaint(). Is that the same thing you are using in your manual ValidateRect() call? Is there a possibility that it is being clobbered during your paint processing? If .rcPaint changed between Begin and End that would explain what you see. You say you use that member to do your re-drawing, read-only? BeginPaint() actually. Like you said though, if it were a bug... which makes me think there must be a problem in my code somewhere. Anyway, found it! Deep in there was a legacy debug routine to update the entire screen. Now to find out who made it and then... Thanks for the suggestions though. Waldermort

I'm guessing that only about 1/5th of this code actual does anything. I would love to just plug it into a debugger and find out exactly what is going on but I gave up on that idea. The only thing I can do now is extract the base algorithms and rewrite the remaining code myself. At this point I'm thinking that even if I had the original code at hand (uncommented), I would probably still have a headache. Waldermort

What exactly do you want to ask ? Is it processor architecture ? Is it C, or C++, or C# ? Is it Win32 / Win64 ? Is it about pointers ? If you (in C/C++/C#) have a BYTE array, then ALL lower bits of an address WILL be used; ohterwise you wouldn't be able to do a bulk read or write from a binary file. Of course, if you do so, you will earn a lot of additional CPU cycles due to misalignment of addresses to WORD / DWORD boundaries, but as cores are so fast now, it doesn't really matters

If you right click on the drive you want to restrict, click on properties and go to the "security" tab, you can change the security permissions for the drive. If you only allow administrators to be able to access the drive content, I believe that if a non-administrator tries to access the drive a UAC box will appear and ask for the administrator password. Hope this helps, --Perspx "The Blue Screen of Death, also known as The Blue Screen of Doom, the "Blue Screen of Fun", "Phatul Exception: The WRECKening" and "Windows Vista", is a multi award-winning game first developed in 1995 by Microsoft" - Uncyclopedia

I am having the same problem. Here I'm using a Windows XP sp2. Did you manage to solve this problem?

WalderMs there a common name for them like 'reparse point' or something? I'm not sure if this is the answer you're looking for, but . is a pointer to the Current directory while .. is a pointer to the parent directory. Michael Martin Australia "I controlled my laughter and simple said "No,I am very busy,so I can't write any code for you". The moment they heard this all the smiling face turned into a sad looking face and one of them farted. So I had to leave the place as soon as possible." - Mr.Prakash One Fine Saturday. 24/04/2004

Thanks for the link, but the 'great firewall of china' prevents me from accessing wikipedia :(( Waldermort

That value of 0xfeeefeee should have given it away. I worked around the issue by throwing out the iterator and used the indexing method instead. Though thanks for the reply :) Waldermort

The AdjustTokenPrivileges function cannot add new privileges to the access token. It can only enable or disable the token's existing privileges. To determine the token's privileges, call the GetTokenInformation function. -Sachin

If you read the other answers, you'll see someone refers to bitfields. That's the important clue - you can look that up in your c++ book, as the full answer is too long for me to bother typing here! Iain.

That's a good description :) Now I can see why it takes so long, walking a linked list of 100,000 items must add quite an overhead. Another reason why delete was taking so long was due to using vld. Perhaps a mapped file may better suit my needs... Waldermort

Roger Stoltz wrote: in this case you would create reusable base classes that you can benefit from later I have to agree there, it's always useful to create re-usable code and add it to a common folder somewhere. I have got to the point now that I am re-using so much code, that I had to create a single header file just to #include my most used snippets. As for this Subject Observer pattern. Most of the examples/articles I found simply pass a this pointer back to the observer through a single virtual method. In my eyes this is somewhat over the top, each observer wouldn't know what type of update or even if the update is relevent, but still have to call back to the subject to check what changed. I took a different approach, much the same as you would normaly use virtual methods. I created a single base class, complete with a list of all virtual calls a class would need. This way the method can be over-ridden directly and whatever updated data is already there. Infact I may even write an article on it. To think of all those projects where I could have used this, but instead took the far more complicated route of multiple derived types and callbacks... Again, thanks for introducing this. Waldermort

Always feels good to find the bug :) --- Yours Truly, The One and Only! web: devmentor.org Design, Code, Test, Debug

Thanks for that. The exceptions are being thrown as a result of using the TreeView_xxx set of macros, using SendMessage instead seems to resolve the problem. Wonder why this is happening? Time to do some googling... Waldermort

Well today I finaly get around to adding the code for the dialog and was hit with something quite unexpected. Setting the parent member of CreateDialogParam() to my custom control, gives me exactly what I wanted. The main window is effectivly unclickable, while the control, dialog and all other applications remain unaffected. Finally, MS got something right. Waldermort

You still working on that, lol. To be honest, I didn't touch that part of my code yet, I'm still working on my class hierarchy. I was thinking to use ShellExec() with the "runas" flag, change the security settings and store them into a file, which I believe cacls is able to do. This should, in theory, allow the origional settings to be replaced once complete. But like I said, I didn't try this yet and probably won't for another week or so. If you manage to do it using another method, I would be interested to see how. Waldermort

The WM_SETFONT does not return a value according to MSDN, also I noted in my post that I did verify that the font has been set. The mistake was simple, I forgot to set the SYMBOL_CHARSET flag. Thanks anyway. Waldermort

WalderMort wrote: I will have to use some type of timer. A timer? Really?  Hmmm, ok.  This doesn't seem like it should be necessary if all the hittest messages are handled properly. Between SetCapture(), TrackMouseEvent(), and WM_MOUSELEAVE there shouldn't be issues with the cursor moving outside the window. Are you doing your own modal resize loop or relying on the system one? It probably bugs you too, but timers in these situations are an extreme, last-resort, cheesy solution IMO :) Mark Mark Salsbery Microsoft MVP - Visual C++ :java: