C / C++ / MFC

moliate21-Apr-02 12:09

moliate

21-Apr-02 12:09

The linker discarded the dll:s, as it found them unneccisary (probably the functions were packaged into COMDATs). If you want to link them in regardless, use /OPT:NOREF instead - or use /VERBOSE to see what was removed.

/moliate

Gaurika Wijeratne21-Apr-02 21:40

Gaurika Wijeratne

21-Apr-02 21:40

How can I use /OPT:NOREF instead - or use /VERBOSE
I mean were to put it.

Thanks

Gaurika..

Gaurika Wijerante

moliate22-Apr-02 4:53

moliate

22-Apr-02 4:53

Project -> Settings -> [Settings for Win32 Release*] -> Link -> Add to project options (add /verbose here)

* I assume you are doing a release build here, as the default for a debug build is /OPT:NOREF

You should now get a lot of information from the linker what is done in each pass.

An introduction to some optimizations the linker does can be found at: http://www.iecc.com/linker/linker11.html

/moliate

Gaurika Wijeratne23-Apr-02 9:12

Gaurika Wijeratne

23-Apr-02 9:12

Dear moliate

Thanks I will Try it.

Gaurika..

Interesting Multithreading Problem :: MFC

Tim Smith23-Apr-02 9:28

Tim Smith

23-Apr-02 9:28

Why in the world would you want to link in DLLs that you aren't using. If you want to get rid of the errors, then remove those DLLs from the link list. Or add them to the exclude list.

Tim Smith

I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?

valikac21-Apr-02 6:16

21-Apr-02 6:16

Hi.

I am stuck in the design process of a small program I am working on. Here is the scenario.

-----
- user select an option in the menu
- main thread creates a dialog box w/ process bar
- dialog box's OnInitDialog() sends a message to main frame
- main frame redirects to view
- view creates a worker thread
- worker thread goes through a for loop // (i = 0, 1 < 10000; ++i);
- worker thread posts a message to main frame on every iteration
- main frame redirects message to view
- view calls a function in dialog box to update process bar
-----

Okay. The design above works fine. Here is one drawback. Even though the worker thread does all the processing (for loop), the main thread is *inaccessible* as it calls the function in the dialog box to update the process bar.

I would like to redesign that part of the program so that even as the worker thread is processing the for loop and as *some thread* updates the process bar, the user can still navigate the program.

Do I need to create a worker thread to update the progress bar? Do I need a UI thread? The reason I kept the dialog box as part of main thread is because according to Prosise, it is best to keep UI related objects in main thread.

Thanks,
Kuphryn

Paul M Watt21-Apr-02 9:13

Paul M Watt

21-Apr-02 9:13

How long does it take your dialog box to update the progress bar? Is that a long complicated process? Is your dialog box modeless?

Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life!

valikac21-Apr-02 9:26

21-Apr-02 9:26

Okay. First, I will answer questions.

1) The interval of the progress bar varies from data to data. Consider, for example, the process of zipping data. Zipping varies from data to data.

2) The dialog box is modeless. The dialog box is a private member in view.

-----

I want to clarify the actual problem. I saw a response from a member that implied that my description was not easy to understand.

The design works fine.

- worker thread handles data processing
- main thread (view) sends messages to dialog box
- dialog box updates the progress bar

The problem is that I believe the process of updating the progress bar is *considered* as part of the main thread. I think the reason is because the dialog box itself is declared in view (main thread).

I need three *independent* processes.

1) data processing
2) dialog box/progress bar updating
3) main thread is idling thus keeps the program from "locking."

Problem: Program seems to "lock" even though the data processing is done in the worker thread.

Question: I believe the reason it seems to "lock" is because as main thread sends message to dialog box to update the progress bar and as the dialog box update the progress bar, the frame considers the entire process (message + updating) as being in the main thread. I need to know a way to make everything separate.

Kuphryn

Paul M Watt21-Apr-02 10:13

Paul M Watt

21-Apr-02 10:13

I would change your update mechanism to be more passive. If you are sending a message to the main thread, then the main thread is calling the update function 10000 times, like you described in your worker thread, that would be a drain on the system.

Have you considered using a timer on the main thread, set to say 1/10th of a second. The timer handler would call the update function of the dialog, and the dialog could use a thread synchronized varaible that indicates the current iteration of your worker loop thread?

Otherwise if your dialog update function depends on processing the data for every iteration, maybe your worker thread could create a report or cache all of the data for the main thread, then the dialog would just have to update a few times a second.

Good Luck!

Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life!

valikac21-Apr-02 11:14

21-Apr-02 11:14

Okay. Thanks.

Kuphryn

Re: Alternatives

valikac22-Apr-02 10:36

How can I make the text backmode tranparent for an edit box without re-output the text?

22-Apr-02 10:36

Okay.

I have consider several different design schemes. One of which is passing a pointer of a dialog box created in view into the worker thread. There, the worker thread can update the dialog box's progress bar. However, I do not think that will solve the problem of "locking." The reason is the dialog box belongs to view, thus it is still apart of view and the main thread. That leaves me with two alternatives opposites of one another.

Alternative #1
- create the dialog box first
- message view after InitDialog()
- view active a function inside of the dialog box
- function instantiate a worker thread that is *part of dialog box*
- worker thread will update the progress bar directly

Alternative #2 (opposite #1)
- create a worker thread
- create a dialog box w/ progress bar *inside of worker thread*
- update the progress bar directly

From the two alternatives, which one do you think is best? I want to make the design as "safe" as possible i.e, non-volatile.

Please mention any ideas you may have.

Thanks,
Kuphryn

Uzi21-Apr-02 5:38

Uzi

21-Apr-02 5:38

I've tried to trap the WM_CTLCOLOREDIT and used SetBkMode(TRANSPARENT), but this only worked for static control, not edit control.

Now I wonder if there's any easy way I can achieve the desired result (that is, no text background) without using any text output function. Please help me!

Uzi

Re: How can I make the text backmode tranparent for an edit box without re-output the text?

Joaquín M López Muñoz21-Apr-02 5:49

Joaquín M López Muñoz

21-Apr-02 5:49

I'd say the solution outlined in Mike Dunn's VC++ FAQ works all the same for edit controls (with the obvious changes.) Otherwise, you can take a look at some of te CEdit derived controls here at CP, some of them provide background transparency.

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo

Thread Synchronization :: MFC

valikac21-Apr-02 5:31

Re: Thread Synchronization :: MFC

21-Apr-02 5:31

Hi.

I am working on a program that utilizes several threads (worker threads). I want to implement a class-safe thread synchronization. In his book, Prosise uses CCriticalSection and CEvent.

I would like to use CCriticalSection with CSingleLock. However, Visual C++ outputted errors when I declared the CCriticalSection and CSingleLock. For example:

-----
// this is in the document class (single)
...
private:
...
CCriticalSection m_cs;
CSingleLock m_sl;
...
};
-----

Visual C++ outputted similar errors referring to both classes. Here are the errors:

-----
d:\C++\MyApp\MyApp.h(96): error C2146: syntax error : missing ';' before identifier 'm_cs'
d:\C++\MyApp\MyApp.h(96): error C2501: 'CMyAppDoc::CCriticalSection' : missing storage-class or type specifiers
d:\C++\MyApp\MyApp.h(96): error C2501: 'CMyAppDoc::m_cs' : missing storage-class or type specifiers
d:\C++\MyApp\MyApp.h(97): error C2146: syntax error : missing ';' before identifier 'm_sl'
d:\C++\MyApp\MyApp.h(97): error C2501: 'CMyAppDoc::CSingleLock' : missing storage-class or type specifiers
d:\C++\MyApp\MyApp.h(97): error C2501: 'CMyAppDoc::m_sl' : missing storage-class or type specifiers
-----

I tried declaring both variable as protected and global. I saw the same errors.

Is there something specific that I need to add to the document interface as in maybe #include <something>?

Thanks,
Kuphryn

Joaquín M López Muñoz21-Apr-02 5:44

Joaquín M López Muñoz

21-Apr-02 5:44

You've got to #include <afxmt.h>. Probably it's a good idea to insert the inclusion in "stdafx.h".

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo

Re: Thread Synchronization :: MFC

valikac21-Apr-02 5:56