Remember: Making a product without selling it is wasteful. Selling a product without making it is fraud.

Our marketing department determines what goes into our packaged product. the list of items is called a Bill Of Materials, or BOM. We finally convinced them to stop talking about updating the BOM, or finishing the BOM while at the airport

Thanks for the imagery. Now I'm going to be quietly chuckling to myself for at least a few hours.

Sorry, I was in a bit of a hurry. Pascal was where I was taught to always define my variables. This was not appreciated by a very old school instructor who taught the FORTRAN class. Fortunately, the Pascal lessons stuck with me a lot better than the FORTRAN ones.

Don't remind me. I was downgraded by a professor for defining variables that just happened to start with i and j. Apparently, Pascal teaches you bad habits :~

I always thought you were supposed to mount a scratch monkey, not an elephant?

If you find simple statements of fact to be offensive, then that's not really my problem now, is it. I'm just the joe that has to deal with these nut jobs and don't really see what will be accomplished by feeding into their paranoid fantasies.

Most of us get by every day without needing to mechanically enhance their manhood like you seem to.

It would appear that CFileDialog contains a function called OnInitdone. The base class for this function contains nothing more than a CenterWindow call, which has been taking all of my work and throwing it away. Overriding this function and not centering the dialog has everything working correctly, with the dialog being placed on whatever monitor I wish.

I don't think it's the documentation for SetWindowPos that is relevant here, but instead the various articles describing how to modify CFileDialog. These articles mention the need to get the parent in order to access the various buttons on the dialog and change it's size. It would appear that this dialog is the child of some other window, but I haven't pulled out win spy yet to see what it is. When I try to get the window rect directly, the returned value indicates a box of zero size, while the parent call returns legitimate values. Likewise, CallingSetWindowPos with on the parent actually moves the window (not off of the screen, unfortunately), but also adjusts it's size.

The documentation I've seen seems to indicate that you have to actually get the parent of the CFileDialog. Since I can manipulate the size of the dialog this way, it would seem that I have the right window. Further experimenting with my test program shows that I can in fact move the location of the dialog a limited amount. It appear, however, that something prevents you from moving the dialog so that any of it is off of the screen. Unfortunately, I need to move it to a second monitor which seems to be a problem.

Is it possible to change the startup location of a CFileDialog? I am working on a legacy application that makes use of multiple monitors, and I need to be able to position the location of the file load/save dialogs. I derived my own class based on CFileDialog and added what I thought was the appropriate SetWindowsPos call in the OnInitDialog method, but the things just will not move. If I change the windows size instead of the position, it correctly truncates the dialog, so I'm fairly sure I have the right window, yet no matter what values I pass in for the position, the location remains the same. Below is the important code from a test program.

BOOL CMyFileDialog::OnInitDialog()
{
CFileDialog::OnInitDialog();

CWnd \*pW = GetParent(); // Get a pointer to the parent window.
RECT Rect;
pW->GetWindowRect(&Rect); //Get rect of parent window

pW->SetWindowPos( NULL, 10, 10, Rect.right - Rect.left, Rect.bottom - Rect.top, 0);

return TRUE;

}

If it makes any difference this is using VS2005.

That's why you should always surround this type of test code with a safety that requires some sort of deliberate configuration change to trigger. I wish I could have learned this before I managed to release an installer with test diagnostic dialogs embedded in it. While our QA team was never able to reproduce the steps needed to trigger things, the customers sure could. :(

I have been tasked with maintaining our companies web site while our current web developer is on leave. While most of the tasks are rather easy even with no web development experience, I'm having some trouble with validating the syntax of my code. Due to the nature of the site, the pages have to be checked onto a staging server before they can actually be run. Doing this takes about 10 minutes, which slows things down quite a bit if you, for example, mismatch your parentheses. Are there any sort of syntax checkers out there that can be run on a file to detect gross mistakes like this? Also, this web site is rather ancient, and the original developer is no longer with the company, leaving both myself and the current web developer at a disadvantage when it comes to determining where things are and how they are laid out. Are there any tools available that can digest a web site and display it's layout? I have encountered large amounts of dead code so far, and with grep being my main tool, simple changes can take a lot longer then they should.

The "show includes" option will give a list of all of the files being included in a source file, but no indication as to which one is causing the rebuild. It doesn't take very many nested includes to make this a non-trivial task.

Under C/C++ - Advanced, there is a show includes option that is close to what I'm interested in. It shows a list of all of the files included by a particular source file. What I'm interested in is the ability to know which header file of that list is responsible for a particular source file being rebuilt. It's been years since I ran makefiles under UNIX, but I remember having this ability.

Is there some sort of option in visual studio to produce a verbose build like the UNIX make command? I have a project with some sort of dependency loop, and it would be useful to know why it wants to build certain files. I know our include dependencies are messed up, and I need to track them down.

Is there any way to convince visual Studio 2003 to tell me why it wants to build a particular file? I have a large solution file that builds a number of dll's executables, etc. If I do a "rebuild all" it happily goes through and rebuilds everything. If I then try to build the solution again, or run it in the debugger, Visual Studio wants to rebuild a bunch of the files all over again. I know I have a circular dependency or two in there, but it would really be nice if I could have the IDE help tell me where it is.

Is there any way to get visual studio 7.1 to tell me why it wants to build a particular file when I build a solution? If I do a clean rebuild of our solution, and then perform another build, it wants to recompile a number of source files. At the moment, I can’t see the dependencies that are causing this rebuild. If I could get Dev Studio to tell me what it thinks the dependencies are it would help.

DavidCrow wrote:

How about: IDR_MAINFRAME1 ICON "..\\res\\MAIN.ico" IDR_MAINFRAME2 ICON "..\\res\\MAIN.ico" IDR_MAINFRAME3 ICON "..\\res\\SECONDARY.ico" ... CMyDlg::CProgressTestDlg(CWnd* pParent /*=NULL*/) : CDialog(CMyDlg::IDD, pParent) { #if defined(APSTUDIO_INVOKED) m_hIcon = AfxGetApp()->LoadIcon(IDR_MAINFRAME1); #elif defined(MAIN_PROG) m_hIcon = AfxGetApp()->LoadIcon(IDR_MAINFRAME2); #else m_hIcon = AfxGetApp()->LoadIcon(IDR_MAINFRAME3); #endif }

If I'm reading the above correctly, this will cause the program to use the correct icon when it is running, but not when the executable is being displayed in explorer, folder browser, etc. It would appear that windows uses the icon with the lowest ID number for for this.