Hello, I would like to make a duplicate of the currently open document via a VBA macro. That is, when running the macro, it will use the current active document as source and make a copy of it without saving it to a file. The current document may be modified (changes were not yet saved to a file), and it could be based on a specific template, with headers/footers/fields. The new copy, should have an identical content (including headers/footers/fields) as the original, based on the same template but with a new name and not saved to a file yet. (The user may save it later if required) Is this possible? Thanks in advance.

-- **Ricky Marek** (_AKA: rbid_) -- "Things are only impossible until they are not" --- Jean-Luc Picard My articles

Question:

Can we use this #pragma comment(ignore 4089) for the warning related to "OLEAUT32.dll" only?

For what I understand, the use of the #pragma is the same as hiding the warning via /IGNORE:4089 in the project settings, which is not the solution I'm looking for. Does anybody has another suggestion? Thanks in advance

-- **Ricky Marek** (_AKA: rbid_) -- "Things are only impossible until they are not" --- Jean-Luc Picard My articles

Hello, When I build the Release configuration of my MFC application I get the following linker warning:

LINK : warning LNK4089: all references to 'OLEAUT32.dll' discarded by /OPT:REF

How can I get rid of this linker warning? (without the use of /IGNORE:4089) Hiding the warning via /IGNORE:4089 in the project settings is not the solution I'm looking for. My guess is that the problem comes from the 7.1 MFC libraries I use... is this true? I'm compiling with Visual Studio 2003 (7.1) Thanks in advance.

-- **Ricky Marek** (_AKA: rbid_) -- "Things are only impossible until they are not" --- Jean-Luc Picard My articles

Hello, I need to add docking support in a dialog based application. Is this possible? (I could not find explicit examples here in CodeProject, most of the examples are for a Single or Multiple Document application and not for a Dialog based application. The docking child window contains several combo boxes and a graph control, this window should be attached to some location in the main dialog window, but can be also "detached" as a modeless dialog. I guess that the child dialog should derive from a CDialogBar...but what to do on the main dialog? Another limitation: I can't use an ActiveX control to contain the docking window as in this example: Docking CSizingControlBar objects inside ActiveX containers[^].. Can someone provide some hint on how to do this? Thanks in advance.

-- **Ricky Marek** (_AKA: rbid_) -- "Things are only impossible until they are not" --- Jean-Luc Picard My articles

Mark Salsbery wrote:

ForumVisual C++ / MFC Subject:Re: Need to make a button (or checkbox) invisible.. Sender:Mark Salsbery Date:13:47 16 May '07 If it's an option, it seems to me it's easier to just intercept WM_LBUTTONDOWN notification messages and check for the cursor being in a certain region. A simple flag to toggle can keep the expert/novice state. Mark

Thanks Mark, Now, how do you intercept the WM_LBUTTONDOWN notification from the main window before the control beneath will intercept and handle it? I have an ActiveX control beneath. (2D Graph ActiveX Control[^])? If this is not possible, can I intercept the notification after the control beneath? Thanks in advance.

-- **Ricky Marek** (_AKA: rbid_) -- "Things are only impossible until they are not" --- Jean-Luc Picard My articles

normanS wrote:

ForumVisual C++ / MFC Subject:Re: Need to make a button (or checkbox) invisible.. Sender:normanS Date:15:44 16 May '07 with the "in" and "out" buttons the colour of the dialog box.

This is a problem for me due that I have an ActiveX control beneath (2D Graph ActiveX Control[^]) has its background changing all the time... therefore making the "invisible button" follow these changes is not easy. :( The solution may be to use a "rectangle" and add some code to intercept when the user clicks on the mouse over it, and if it is in the rectangle do something otherwise call the 2D Graph ActiveX Control[^] handler for the mouse click. (But I'm not sure if this will work)

-- **Ricky Marek** (_AKA: rbid_) -- "Things are only impossible until they are not" --- Jean-Luc Picard My articles

Hello, Scenario: MFC dialog application. That contains a lot of regular controls but should also contain a hidden(invisible) button or checkbox. clicking on the button (or checkbox) will enable or disable some custom or expert capabilities. Only knowing the exact location of the button will allow the user to click and get the expert capabilities. The invisible control should behave as a regular visible control. I know that this is possible, due that I saw it on a demo application few years ago (That I don't remember its name), but I don't have the vague idea on how to code it. Any idea on how to implement it with Visual C++ using MFC? Thanks in advance.

-- **Ricky Marek** (_AKA: rbid_) -- "Things are only impossible until they are not" --- Jean-Luc Picard My articles

Hello to all, First of all, thanks for your help in trying to solve this problem. The problem is solved, and was caused by variable aliasing that confused the compiler optimizations. The code that caused the problem has been re-designed and fixed. (I found also other spaguetti programming problems there). How was this problem isolated

• First I added to the beginning and end of all source files (not header files) the following line:

  // Add at the beggining of the file:
  #pragma optimize( "", off )
  ...
  // Add at the end of the file:
  #pragma optimize ("", on )

• Then file by file, once a time I removed the pragma to see if the problem appears, if yes, mark the file as problematic and continue to the next file.(restoring the #pragma to the beggining of it)

• Once I finished with all files, and ending with a pair of problematic files, I started to do the same for isolating the "functions" that caused the problem.

// Add before the function body:
#pragma optimize( "", off )
...
// Add after the function closinc brace:
#pragma optimize ("", on )

• At the end, I found that only a small number of functions were the ones that caused the problem, and the reason was variable aliasing.

The code was belonging to a novice developer, that with my help he has re-designed his code and now we all are happy :) Note: Variable aliasing is described in the VC documentation, look under Compiler Optimizations, specially for the flags /Ow or /Oa. Thanks to all who helped me to identify the problem. -- **Ricky Marek** (_AKA: rbid_) -- "Things are only impossible until they are not" --- Jean-Luc Picard My articles

Ryan Binns wrote:

ForumVisual C++ / MFC Subject:Re: Release Code Optimization Problems.. Sender:Ryan Binns Date:20:38 20 May '06 One other thing you could try is to enable optimisation for your debug build and see if it has the same problem. If it does, you can step through it with the debugger. You won't be able to go one line at a time, but you should be able to narrow it down enough to find the problem area. Ryan

I'm using your sugestion together with the sugestion in: http://www.codeproject.com/script/comments/forums.asp?forumid=1647&select=1497199&fr=364&df=100#xx1497199xx[^] So far, I managed to isolate a bunch of files that cause the problem, it seems that the developer that wrote that code was not aware about aliased code. (I asked him to take a look and maybe re-design some code that causes the problem.) I will sumarize the results. Thanks. -- **Ricky Marek** (_AKA: rbid_) -- "Things are only impossible until they are not" --- Jean-Luc Picard My articles

Saurabh.Garg wrote:

ForumVisual C++ / MFC Subject:Re: Release Code Optimization Problems.. Sender:Saurabh.Garg Date:22:36 21 May '06 So were you able to solve the problem. It would be nice if you can share what type of code can cause optimization problems. -Saurabh

I'm still fighting with it. But at least, I know which files are the cause. It seems that the developer was not aware that optimizations could cause some aliasing..about aliasing. (Using pointers to variables that the compiler may supress during optimization) Look in:

• Writing Efficient C and C Code Optimization[^]
• Look forAssume No Aliasing, Assume Aliasing Across Function Calls in the MSDN documentation (I could not find the internet link)

I will sumarize when I finish my investigation. -- **Ricky Marek** (_AKA: rbid_) -- "Things are only impossible until they are not" --- Jean-Luc Picard My articles

Saurabh.Garg wrote:

ForumVisual C++ / MFC Subject:Re: Release Code Optimization Problems.. Sender:Saurabh.Garg Date:22:21 20 May '06 Oh I interpreted your question incorrectly. In this case you can selectly turn off optimizations using #pragma optimize( "", off ) . . . #pragma optimize( "", on )

Eureka:-D, thanks for the idea. (It is so simple when you know it :) ). Thanks. -- **Ricky Marek** (_AKA: rbid_) -- "Things are only impossible until they are not" --- Jean-Luc Picard My articles

Another way to do it: Using CFileStatus from MFC..

CString folderPath = \_T("C:\\\\DK\\\\Index");

CFileStatus status;
if(!CFile::GetStatus( folderPath, status ) )   // static function
{
    AfxMessageBox(\_T("Directory does not exist.(\\"") + folderPath + \_T("\\")\\n"),
                  MB\_OK|MB\_ICONINFORMATION);
    ...
}

The use of _access (posted by Chris Losinger) may be more suitable for your needs. -- **Ricky Marek** (_AKA: rbid_) -- "Things are only impossible until they are not" --- Jean-Luc Picard My articles

Ray Hagstrom wrote:

ForumVisual C++ / MFC Subject:Re: Release Code Optimization Problems.. Sender:Ray Hagstrom Date:14:46 20 May '06 Sounds a lot like scientific programming.

I'm doing some system verification code, the system guys use Matlab for generating their models, and I run some "C" code to verify their models.

Ray Hagstrom wrote:

1.)Array overrun (Solution: interface array access through an intermediary function that executes a bunch of assert(); to verify that access is always within bounds. The asserts all dissappear in the release mode so that they do not slow production down at all.)

Yes, But this could also happen in the Debug or Release without speed optimization, and it does not happen, the problem arises only when I compile the code with speed optimization (/O2 flag) (PC-Lint[^] did not find any access out of bounds in the code)

Ray Hagstrom wrote:

2.)Optimizer bug. (Here the machine-code generated by the compiler is just flat wrong. Every mature scientific programmer must be prepared to deal with this horrible sort of problem. I have NEVER (since 1965) dealt with a compiler that I did not find bugs in its code generation. Here, my best approach is to start backward from the crash line. Either some datum going into the crash is wrong or the line is encoded wrong.)

The program does not crash, but produces wrong results when compiled with the optimize for speed flag. I'm currently adding some TRACE lines to print out the computed results and then compare them with the Debug (or Release without code optimization).. but that is like looking for a needle in a montain of hay :(( Any additional hint? Thanks to all in advance. :rose: -- **Ricky Marek** (_AKA: rbid_) -- "Things are only impossible until they are not" --- Jean-Luc Picard My articles

Ryan Binns wrote:

ForumVisual C++ / MFC Subject:Re: Release Code Optimization Problems.. Sender:Ryan Binns Date:7:53 20 May '06 I hate those problems. There's almost nothing you can do to determine the problem. The only way I've been able to sort it out reliably is to narrow down to a particular section of code by comparing the results with what is expected every few lines, and flag an error (a message box or debug trace) when they don't match. When you can find out which section of code causes the problem, check it extremely carefully to catch things that might be dependent on the compiler moving statements around, and possibly rewrite the code. Even if it's slightly less efficient, the extra speed you get with optimisation will probably make it worthwhile.

Yes, you have interpreted my question correctly. I guess that I will continue to dumping (via TRACE) debug information to catch the problem, it is like looking for a needle in a montain of hay. and even worse, the problem is detected only after running for almost 1hour. (That is the reason why speed optimizations are required) Thanks for your help. -- **Ricky Marek** (_AKA: rbid_) -- "Things are only impossible until they are not" --- Jean-Luc Picard My articles

Saurabh.Garg wrote:

ForumVisual C++ / MFC Subject:Re: Release Code Optimization Problems.. Sender:Saurabh.Garg Date:4:32 20 May '06 If a code runs in debug mode and not in release mode then most probably there is a bug in the code, which is exposed in release mode due to optimizations. If you are using VS 2005 (this might work with VS 2003 also but I am not sure since I never used it) then its simple, just put break point in the code and let then program run under debugger. When program crashes visual studio will give you an option of breaking into the code. This way you will know where exactly is the problem. Hope this helps. -Saurabh

You are right, but the code does not crash, just gives a different result that is not acceptable. Puting a breakpoint or dumping via TRACE or printf is like searching for needle in a montain of hay (or how you say it).. I'm running VS 2003. A great article about Surviving the Release version[^] can be found in this site as well.. I'm also thinking about what is mentioned [here](http://www.codeproject.com/debug/survivereleasever.asp#Compiler Bugs (again))[[^](http://www.codeproject.com/debug/survivereleasever.asp#Compiler Bugs (again) "New Window")]. Have a nice day. -- **Ricky Marek** (_AKA: rbid_) -- "Things are only impossible until they are not" --- Jean-Luc Picard My articles

A_Laxman wrote:

rbid wrote: All this code runs under the same thread Create the seperate synchronised threads for the large calculations and which is not much dependent on each other

This is exactly how it is implemented. The code that has the problem runs on a separate synchronized thread. Even if I encapsulate the code on a single "console application", the problem persists. Thanks for your thoughts, this place is a great place for getting good ideas and solutions. -- **Ricky Marek** (_AKA: rbid_) -- "Things are only impossible until they are not" --- Jean-Luc Picard My articles

There is another way to do it :)

• Assign a "Control" variable to your edit box (CEdit m_textEdit).
• Use the method GetWindowText() for retrieving the results

void CDemo::OnBnClickedSearchButton()
{
...
CString userResponseText;
m_textEdit.GetWindowText(userResponseText);

// userResponseText now contains user response..
...

}

Here you don't need to worry about UpdateData that usually has side effects. Just wanted to give you another way to do it. -- **Ricky Marek** (_AKA: rbid_) -- "Things are only impossible until they are not" --- Jean-Luc Picard My articles

Hello, SCENARIO:

• I have some "C" code that runs heavy math, that takes time to get the results.
• Compiling under a Debug configuration, all goes as required.. but the run sessing is to slow (few hours to get the results.)
• Compiling under a Release configuration, fails to get the required results.
  (Release configuration with its default Speed code optimization (/O2 flag))
• When I turn off speed optimizations under Release configurations, the results are O.K, but again, it runs slower than expected.

QUESTIONS

1. How can I detect what does causes this differences on the code?
2. How can I debug this code and catch the affecting lines?

I guess that this has to do in the way this "C" code is written, that optimizing it for speed causes the differences. All this code runs under the same thread, and uses data that is static. Any hint?:sigh::confused: Thanks in Advance. -- **Ricky Marek** (_AKA: rbid_) -- "Things are only impossible until they are not" --- Jean-Luc Picard My articles

It is so simple when you know it :) -- **Ricky Marek** (_AKA: rbid_) -- "Things are only impossible until they are not" --- Jean-Luc Picard My articles

Hello, In addition to catching the WM_CLOSE event, I would like to disable the close icon on the dialog title bar when some critical section is being parsed in my application. Is this possible?, For those that use Nero Burning Room, when you are burning a CD/DVD, the close icon on the dialog title bar is dissabled.. How can be this done under MFC? http://img82.imageshack.us/img82/1588/disableclose7uy.gif[^] I guess that the style of the window is changed with SetWindowLong(), but I don't manage to find how. Thanks in advance. -- **Ricky Marek** (_AKA: rbid_) -- "Things are only impossible until they are not" --- Jean-Luc Picard My articles