Greetings, This is not a new idea, but it is something I've finally implemented. I find that when I start up a new project there are a bunch of things that I want to do before I get started programming. I want to fix the "Untitled" bug, add tooltips, add a general purpose regular expression class (based on VBScript), add auto-incrementing versioning, add command-line parsing, add saving/restoring window placement information, etc., etc., aud nauseum. You know how that works. Nothing hard to do but it takes time and I always forget to do it or don't do them all. I have often thought that I should just setup a prototype project to use as a basis for all my future projects but the renaming chore is ghastly. I could setup some VS templates, but that looks like a daunting task in its own right. Then I discovered some free VS project renaming utilities. They've been around forever, I just didn't know how easy and reliable they are: http://adunk.ozehosting.com/software/RenameVSProject.html[^] and http://www.codeproject.com/KB/cpp/vsrename.aspx[^] These are so easy, that now I have my prototype projects and I can cut about an hour getting started. Who knew? I wish I had done this years ago!

Great! Glad to hear it.

I was just looking in the above section and noticed that there are hundreds of articles in dozens of categories. To find something of interest can take quite a while to scan the entire list. If there were a linkable Table of Contents at the top (as with other parts of Code Project) then it would be much easier to use. Also, I noticed that the font changes about 2/3 of the way down to a bolder font. Did some font change get left open?

Andy Brummer wrote:

I think Mike was referring to writing code that depends on the user having a particular keyboard layout selected. Writing code that is dependent on something like that is just asking for it to break. It should be able to access all the files directly without having to deal with keyboard layouts.

I understand. However, I believe that the code involved (I have not seen it myself, so this is 2nd hand info) uses standard, low-level, editor commands (Edit.GoTo, Edit.Find, Edit.LineCut, whatever) which may have been redefined by the Emacs layout. Further, many people are not even aware that other keyboard layouts are available and so would not have thought to check for this. The fact is, most of the code we all write is perfect until somebody uses it in an unanticipated manner. I just don't think that being critical of somebody's work, that has survived for many years, on the basis of holier-than-thou is appropriate. I also hadn't anticipated this much of a debate! :laugh:

Well, it apparently breaks the AddIn wizard and the MS guy also said it broke another wizard. Of course, very few people use the Emacs keyboard layout so almost nobody runs into this problem. The MS guy sent me an addin (!) to fix this problem that temporarily changes the keyboard layout to "Default" during the AddIn wizard operations, and then restores it. I haven't tried it yet as I am still working on my very first addin and haven't needed the wizard again.

Mike Dimmick wrote:

I'd never write anything that fragile

I don't think that I would call it "fragile" as it is really the problem with the Emacs keyboard layout which redefines the meaning of some basic text editor operations...

I found a bizarre bug (now confirmed as a bug by Microsoft) in the AddIn Wizard. If you have selected the Emacs keyboard layout, the wizard will hang! Turns out that the wizard actually uses the VS text editors to fill in some values in a template and the script is not compatible with the Emacs layout. The fix is to just change to the default Visual Studio keyboard layout, run the Wizard, and then change back. Oddly, this bug was already in the MS bug list database, but you need to know that this is related to Emacs to find the entry. And if you know that, then you already have the workaround. Sigh.

Got it, thanks!

Hi, This is a re-post from the Lounge as I didn't know where to report problems with CodeProject pages. Someone there directed me to here. I've been getting Javascript errors on most of the CodeProject pages (particularly article pages) and I wanted to report them to the webmaster. However, I cannot locate a "contact us" link or anything resembling it. Also, the "About Us" link under the Help! drop-down never returns. No place seems to be listed on the site map. I'm hoping the webmaster reads this forum regularly. Anyway, most pages have a message like "Highlight is not defined" (I am viewing with Firefox. Forgive me.) The debugger shows things like this: <script language="javascript" DEFER>Highlight(Array());</script> <h2>=>About Nibu babu thomas</h2> It doesn't really bother me that much, but it seems a shame to have this on such a nicely formatted web site, doesn't it.

Hi, I've been getting Javascript errors on most of the CodeProject pages and I wanted to report them to the webmaster. However, I cannot locate a "contact us" link or anything resembling it. Also, the "About Us" link under the Help! drop-down never returns. No place seems to be listed on the site map. I'm hoping the webmaster reads this forum regularly. Anyway, most pages have a message like "Highlight is not defined" (I am viewing with Firefox. Forgive me.) The debugger shows things like this:

Highlight(Array());
<h2>=>About Nibu babu thomas</h2>

It doesn't really bother me that much, but it seems a shame to have this on such a nicely formatted web site, doesn't it.

But it does cause an abort. Not always a nice thing for an embedded system. Thus the need to write an alternative.

Gary R. Wheeler wrote:

The question remains, why are you implementing your own assert function? assert is provided for you.

I don't know Nacho's reason, but I have the need to be able to comprehensively report an error (file, line, function, and stack trace) and then continue the program with error recovery. The idea is that a customer could snap the info and report it back and then I would have a fighting chance of figuring out the problem. And if automatic error recovery worked, then the customer is not facing a complete crash like assert() gives. Further, not all code runs under Windows. An heretical thought, but there it is! :laugh:

E.Satish wrote:

i want to know how to increment a int value when i press and hold a button , if i release the button increment must stop

I don't want to blow my own horn, but here is my solution to this from years ago: Simple Auto-Repeat (Fire Control) Button Control: http://www.codeproject.com/buttonctrl/repeatbutton.asp[^] I haven't had occasion to use this since VC6 but it shouldn't be difficult to adapt to your needs.

Greetings, First, I apologize for what must be in a FAQ somewhere that I haven't located. I have tried. Here is the basic question (details below): How do I turn off canonical input processing on an arbritrary istream? Failing that, how do I do it with just cin using VC++ 7.1? The gory details: I am writing a function that is part of a larger project so I don't have a lot of control over the style of its parameters. It gets an istream and ostream pointer. With the istream pointer I have to read a character at a time as this is for an interactive application; I need to react to each character as it is entered, not after the entire line has been entered. Like an editor. But if the istream is std::cin, then I have canonical line processing (no extra charge!) where the characters are echoed to the user, ^H (backspace) is interpreted, and nothing is available to the calling program until a newline has been entered. If I compile under GCC 3.4.4, I can (with vast pain) determine that the istream is associated with file descriptor 0 (STDIN_FILENO) and use tcgetattr/tcsetattr to turn off the canonical processing. But these functions (tcgetattr/tcsetattr) do not appear to be available in VC++ 7.1 I have looked for days for a general way to deal with this problem and either it is so obvious that nobody mentions it or I have completely missed it. Even the GCC documentation doesn't give a solution for itself (though I found one on the net). The VC++ documentation casually mentions that istream buffering can be turned off, but doesn't say how. Perhaps they were not referring to canonical processing but something else... I have tried some of the obvious stuff already: // Forcing cin to not do line-buffering and echoing #include #include using namespace std; int main(int argc, char *argv[]) { char inChar; #if 0 // compiles but input is still line-buffered cin.rdbuf()->pubsetbuf(0,0); #endif #if 0 // doesn't compile under cygwin g++ 3.4.4 or VC++ 7.1 // It was mentioned somewhere on the net so I had to try... cin.setbuf(0,0); #endif #if 0 // According to MS, cin is really an ostream (!), so... // compiles but input is still line-buffered (wasn't really expecting much) cin >> unitbuf; #endif #if 0 // compiles but input is still line-buffered (wasn't really expecting much) cin.setf(ios::unitbuf); #endif while(cin) { cin.get(inChar); if(inChar == '\004') break; cout << "\nRead in '" << inChar << "'\n" <<

K(arl) wrote: As I understand it, you want to force the size of your application. I would do so by resizing the MainFrame object, using CMainFrame::SetWindowPos. Then I would catch the WM_SIZE message in the Form View to handle controls size and position changes. Oh, and you can manage the way your view handles scroll bars by overring CScrollView::SetScrollSizes. OK, now I understand what you meant. What I am doing now is use WindowSetPos() and SetScrollSizes. Pretty much as you suggested. I didn't understand from the documentation what SetScrollSizes did. It just sets the the threhold for window size for when the scrollbars appear. Which is what I needed. Thanks for your help.

I'll try that when I get home. Thanks!

K(arl) wrote: As I understand it, you want to force the size of your application. I would do so by resizing the MainFrame object, using CMainFrame::SetWindowPos. Then I would catch the WM_SIZE message in the Form View to handle controls size and position changes. Yes, I want to set the size of the application. I've tried using SetWindowPos(), but it works no better. Catching the OnSize stuff would not help as the control has already been sized; there is nothing to be done. Manually (or rather programatically) adjusting the scroll bar is something I would like to avoid. For now, I am using a kludge by setting the original size of the Formview and the control that gets resized (in the visual dialog editor) to something absurdly small. Then when I load up the control and resize it, I can also resize the MainFrame and it seems to work. No annoying, unneeded scrollbars appear. But this seems like an inelegant solution. Surely there is a better way!

Greetings, I am trying to change the size of a FormView application after I have resized a control and I must be missing something essential. I can get the window to resize (smaller), but then scroll bars appear that weren't there before. I suspect it is something inherent to how a FormView works as when I resize smaller manually, the scroll bars appear even though no controls are obscured. I suspect I have some setting in the FormView wrong since it doesn't behave with manual resizing. Anyway... My current approach is to call AfxGetMainWnd()->GetWindowPos(), adjust the values and then call SetWindowPos(). Then I call ResizeParentToFit() which almost does the job. Here is a code fragment. The control involved is a CListCtrl...

WINDOWPLACEMENT wpMain, wpOldList;
AfxGetMainWnd()->GetWindowPlacement(&wpMain);
m_RecordList.GetWindowPlacement(&wpOldList);

... make the size and content changes to the list ...

WINDOWPLACEMENT wpNewList;
m_RecordList.GetWindowPlacement(&wpNewList);

int sizeChange = wpOldList.rcNormalPosition.right - wpNewList.rcNormalPosition.right;
wpMain.rcNormalPosition.right -= sizeChange;
AfxGetMainWnd()->SetWindowPlacement(&wpMain);
ResizeParentToFit();

Any hints would be greatly appreciated. Thanks!

You should be aware that this is a religious subject; people of one faith will ignore all arguments from heretics. And converts tend to be evangelistic! :) IMHO, unless you need to do low-level hardware access or are in an extremely tight loop, assembly code should never be seen. And if it is, it should be heavily commented. Remember, the vast majority of the life-cycle of a piece of software is in the maintenance phase, not development -- assuming it is a successful program! And assembly is harder to read and hard to port. Even when porting from one compiler to another for the same target processor, porting can be awkward as different compilers have different assembly escapes, stack conventions, internal symbol representations, etc. Further, modern compilers are smart. Even things like x <<=1; instead of the more readable x *= 2; don't buy you anything as the compiler understands what *= 2 means and will find the best way to accomplish this. If you really are concerned about optimization in a tight loop, then optimize your algorithm (always your best bang for the buck) and adjust variables such that a minimum of assembly-level conversions are needed. For instance, use the machine's natural size integer (usually int) instead of a short. If the compiler cannot determine the absolute maximum value and the processor doesn't handle shorts as easily as ints, then a low-level conversion might be needed. Try peeking at the generated assembly. And heavily comment such tweaks!

This is something of a religious subject in that people have certain beliefs and will not change them whatever the argument. And those that do convert, tend to froth at the mouth! :) However, IMHO, unless you need to do low-level access to hardware, or you have something in an extremely tight loop, assembly code should not ever be seen. Remember, the vast majority of the life-cycle of a program is in the maintenance phase and assembly is harder to read and understand than a higher level language. And porting is an issue with assembly, even if on the same processor -- different compilers handle assembly escapes differently. And modern compilers are pretty good. If you think about how the code is liable to be translated (or peek at the generated code), you can optimize the C/C++ code to make very good machine code. Things like using the natural size integer for a processor rather than something that needs conversion, e.g, use an int rather than a short for a number so low level conversion doesn't have to happen. Naturally, such code should be heavily commented. As an aside, certain kinds of optimizations that programmers often use because they think they are smarter than the compiler are not needed. For instance, doing x <<= 1; in instead of x *= 2; is almost never needed. The compiler can figure this out just fine. And the first is harder to read...

Henry miller wrote: If you want some example source code, search for "diff", which is a unix utility that does what you want. (and many other things) Good idea. However, "diff" is for text files. If you want to compare binary files, try the unix utility "cmp" If you don't have the source to the unix utilities, try looking at cygwin, a Unix-on-DOS implementation: http://www.cygwin.com[^]