|
Some web servers requrie a valid Host: entry which is usually
Host: <your ip>
and some even check the Agent: header
Agent: Mozilla (blah blah)
Todd Smith
|
|
|
|
|
The GET line should contain the full URL and HTTP version:
GET http:
|
|
|
|
|
Okay. Thanks.
I will try that approach.
Some server require the Host to be exact. For instance, www.xyz.com might want members.xyz.com. There is no way to determine what the server wants without first seeing an error response.
Kuphryn
|
|
|
|
|
hi everyonebody,
i have a popup menu, activated by right click.. i want to disable some of the commands in the menu.. i was wondering how do i do it? i've different ways, but i can't seem to get it working.. any suggestion is welcome.. thanx in advance.
i've tried this:
void CMyApp::OnRMrclk(....)
{
CMenu menu;
CPoint point = GetMessagePos();
menu.LoadMenu(IDR_MENU1);
menu.EnableMenuItem(ID_MENU1_ONE, MF_GRAYED);
menu.GetSubMenu(0)->TrackPopupMenu(TPM_LEFTALIGN | TPM_RIGHTBUTTON, point.x, point.y, AfxGetMainWnd());
}
i've also tried this:
void CMyApp::OnUpdateMenu1One(CCmdUI *pCmdUI)
{
CMenu * pMenu = pCmdUI->m_pMenu;
pMenu->EnableMenuItem(ID_MENU1_ONE, MF_GRAYED);
}
|
|
|
|
|
|
Every once in a while I hear this pop up that break statements should only be used in switch statements and continue is just bad.
IMHO, this is a question of style and thus I am not interested in if it is right or wrong. What I would like to know, how many people think that break/continue are bad and how many do not.
So? What do you guys think?
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
I don't like using them except as you say break should be used in switch statements.
|
|
|
|
|
I use break all the time to exit simple loops (yes, I know this is a "violation of structured blah blah..." but I couldn't care less ). As for continue, I don't use it that much.
|
|
|
|
|
All generalizations are false.
break and continue have their place. Every programmer knows what they do, so using them won't cause others to scratch their heads in confusion. (Unlike something more esoteric, like say complex templates.) If the code is readable with those statements, then by all means use them.
--Mike--
If it doesn't move and it should: WD-40. If it moves and it shouldn't: duct tape.
1ClickPicGrabber - Grab & organize pictures from your favorite web pages, with 1 click!
My really out-of-date homepage
Sonork-100.19012 Acid_Helm
|
|
|
|
|
break in a for loop often shows a while loop should have been used. In switch statements, I don't see what the problem is.
Christian
No offense, but I don't really want to encourage the creation of another VB developer.
- Larry Antram 22 Oct 2002
C# will attract all comers, where VB is for IT Journalists and managers - Michael
P Butler 05-12-2002
Again, you can screw up a C/C++ program just as easily as a VB program. OK, maybe not
as easily, but it's certainly doable. - Jamie Nordmeyer - 15-Nov-2002
|
|
|
|
|
I think those break /continue discussions, as well as some other structured programming mottos like "one return for function" are a little outdated these days. Most complexity in today's programs comes (hopefully) from OOP architecture, not the design of local code. Personally, I tend to use whatever resources that make the code more understandable and/or simple, and break s inside loops are often very handy.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
I love them. I think they can make for more readable,
better documented loops-- especially in those loops
with large bodies. I say use them when control flow
is easier to picture because of it. I personally hate
to read code that is deeply nested for no other reason
than style.
|
|
|
|
|
Hi,
I have radio buttons in my dialog and want to disable some of them according to the state of other radio buttons. The problem is that it seems impossible to add a member variable for radio buttons in MVC++6! (but check boxes are ok)
I basically want to do the following:
m_radioButton1.EnableWindow(false);
Thanks
|
|
|
|
|
the Wizard will create only one variable for a radio button group, the one variable contains the "index" of the radio button of the group that is chosen.
I think you can add them manually ( preferrable since you'll learn something more ! )
you can always do :
CButton* pButton = (CButton*)GetDlgItem( IDC_RADIO_BUTTON1 );
pButton->EnableWindow( FALSE );
Max.
|
|
|
|
|
Thank you a lot Max
|
|
|
|
|
|
Nishant S wrote:
Assuming I want to hook the registry, what are the pros and cons of doing it in user mode and doing it in kernel mode?
Not sure that this will entirely help, but here is a shot on MSDN:
Choosing User Mode or Kernel Mode[^]
Nick Parker
You see the Standards change. - Fellow co-worker
|
|
|
|
|
Did you have a look at the regmon [^] tool from sysinternals.
They have the source for that tool. I'm sure it would be a good starting point.
regards
Kannan
|
|
|
|
|
I had a conversation with a friend of mine and he was determined that exceptions were bad if you could get the same effect from returning an error code instead of throwing an exception. Some of the reasons where that exceptions incur way too much overhead, are overly complex and not portable. Are these arguments correct? Also, are there any documents that cover this topic extensively for pros and cons?
Cheers,
Clint
|
|
|
|
|
The problem with checking error codes is that people don't do it. Throwing an exception *forces* your app to deal with them (or die a horrible death).
Exceptions incur overhead, yes, but they should be only used in exceptional cases i.e. for things that should never happen. For example, if you're opening a file you should handle the case where the file is not there. If it's a user opening a Word document, that's a reasonable situation and can be handled by a return code. But if the file *should* be there, that's an exception.
And ask your friend how they are not portable! They are.
Scott Meyers "Effective C++" books are always a good place to start for this kind of thing.
he he he. I like it in the kitchen! - Marc Clifton (on taking the heat when being flamed)
Awasu v0.4a[^]: A free RSS reader with support for Code Project.
|
|
|
|
|
Exceptions don't require you to handle them. As you said yourself, you just die a nasty death. I really doubt that the people who don't check return code care about exceptions.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
Tim Smith wrote:
I really doubt that the people who don't check return code care about exceptions.
Ditto.
|
|
|
|
|
Exceptions aren't bad. That notion is basically silly. However, I personally don't use them since I don't see much need for them and I wonder if there has been any research that shows they produce more bug free code. Since I do check return code, exceptions just tend to make my code harder to write. But then having to properly handle return codes can also produce icky code.
IMHO, it is personal preference. They are portable. Many implementations are now VERY lightweight. And as someone else stated, yes, throwing an exception does require serious resources, but in general exceptions shouldn't be used for normal program flow. They are, after all, exceptions.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
I would say that exceptions are an important tool in well written code. Return error codes are good and should be used when it is adequate, but there are serious limitations to return codes. Also, return codes and exceptions are not an all or nothing propisition. Where return codes fall apart is when you need to provide more information about a failure. Yes, there is overhead to exceptions but they are portable. I am working on an article for CP which will cover this topic.
Here's an example that I think basically explains the pros-and-cons of each error method.
I have a function in one of my apps called ScanDirectory which searches a directory for specific file types (they are DLL's), loads them and executes a specific function.
The function prototype looks something like:
short ScanDirectory(LPCTSTR lpszDir)
The ScanDirectory function can return one of the following values which I believe are self explanatory.
0 - All requested files loaded
1 - Directory does not exist
2 - Directory is empty
3 - No files of requested type in directory
This function is required to load ALL dlls succesfully or fail. If this function attempts to load a DLL and fails, I throw an exception. I do this because I want to report back to the calling function what DLL failed to load, the reason it failed to load and any other infomration I have on the error.
Just my 2 cents.
|
|
|
|
|
Exceptions are a great way to write clean and maintainable code. Their benefits far outweigh any extra-overhead concerns you may have. You can just read lines of code without being distracted by the all the possible error conditions that can come from every method call. Then if you're really interested in seeing how errors are handled, you go to one or two places in the code that catch the exceptions, instead of all over the place.
A great argument for using exceptions that comes to mind is the new languages such as Java and the .NET ones. They all make extensive use of exceptions in their libraries. It's interesting to note that in C++, exceptions have more overhead because the compiler has to deal with calling destructors for all the locally defined objects, in addition to unwinding the stack. Still, it's probably not a lot less innefficient than the code the compiler executes when a regular block is closed.
Of course, it should be noted how to properly use exceptions. They should be thrown only in the case of errors that cause the flow of the code to be interrupted, and should be caught only in places that can properly deal with them.
Regards,
Alvaro
Well done is better than well said. -- Benjamin Franklin
(I actually prefer medium-well.)
|
|
|
|