C / C++ / MFC

Event for CDialogBar Docking & Floating

24-Jul-02 19:42

Is the dialog a modal dialog (stops program execution until you close the dialog). If so the only thing that you will be able to do is modify the code inside the DllFuncDlg() function to make sure that the dialog is brought to the foreground with a call to SetForegroundWindow().

Otherwise if the ServerMethodAAA function returns and the dialog is a modeless dialog, then you can call SetForegroundWindow right after your call to ServerMethodAAA.

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!

Dave Matrix24-Jul-02 19:21

Dave Matrix

24-Jul-02 19:21

Hi there,
Can u pls tell me the events to be trapped to know when a CDialogBar is 1]Docking and 2]Floating?
I need to resize my frame programatically, whenever the dialog bar is docked and floated and docked back.
Thankx Very much
Dave Smile | :)

Going Crazy: Trying to inherit an interface from another dll

doshin24-Jul-02 19:03

doshin

24-Jul-02 19:03

Before I get started, I should warn you that most development I have done has been in VB.

Now that the laughter has subsided, here is the problem:

I have the following:

IBaseData - An interface in a dll which will not contain any implementation code.

ISybaseData - An interface which I would like to inherit from IBaseData INSTEAD of IDispatch.

I get an error that says unresolved type declaration IBaseData in the SybaseData project. Does anyone know what I am doing wrong?

EDIT: The SybaseData dll has a static link (#import) to BaseData project. Is that wrong?

Note: When I have BOTH interfaces in the same project, and I hack around the .idl file it works fine and I get the desired effect. But when I try to inherit it from another project (dll) I get that error.

Goal: To be able to do have a client app have a static link to the BaseData dll. After I create the smart pointer, I can then load by Classname "SybaseData.MyData" onto the smart pointer because they export the same functions, but a different implementation. In the future, I would like to create a "OracleData.MyData" dll and so forth and so on. Am I going about this the wrong way? I would rather not do use Invoke because it is a pain to set up.

Please let me know if you need any clarification, as the entire post is probably a bit confusing Wink | ;)

Re: Going Crazy: Trying to inherit an interface from another dll

Paul M Watt24-Jul-02 19:24

Re: Going Crazy: Trying to inherit an interface from another dll

24-Jul-02 19:24

If I am understanding your question correctly, you want to derive your new class from an existing interface. This interface exists in a separate DLL with a type library. Currently you are going to create one implementation of this interface, called SybaseData, inthe future you may create a different version of that interface called OracleData.

With that out of the way, either way that you are doing it is valid. If you use the #import statement in your IDL file, it will create the interface definitions automatically for you and make them available to the MIDL compiler.

Alternatively you could redeclare the IBaseData class yourself in your IDL file. As long as the guid matches and the interface is identical that method is valid as well.

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!

doshin24-Jul-02 19:32

doshin

24-Jul-02 19:32

Incredible. Thanks for the quick and informative reply, kilowatt.

The odd thing is that the #import IS indeed in my idl file and I still get "unresolved type declaration". The second method (which I didn't think of) should work, but I would really like the first method to work if possible.

Also, is this the "right" way to write a data abstraction layer? I would rather not have different rdbms code comingled in the same dll and unfortunately for this project, stored procedures aren't available.

EDIT: The #import is pointing to the BaseData.dll, if that helps.

Thanks in advance.

Re: Going Crazy: Trying to inherit an interface from another dll

Paul M Watt24-Jul-02 19:48

Re: Going Crazy: Trying to inherit an interface from another dll

24-Jul-02 19:48

Does your BaseData.dll file have a typelibrary definition? That is the only way that the MIDL compiler will be able to extract the IDL definition for you new dll to use. A very easy way to tell is by referencing your BaseData.dll to a visual basic project. If VB finds the components or even interfaces inside of your dll, tehn it has a typelibrary.

If you do not have a type library inside of your BaseDLL then you will need to add the definition at the bottom of your IDL file for it.

One other way to do this is to import the IDL definition from your BaseDLL project if you used an IDL file originally.

If you want you can email me with more info.

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!

Paul M Watt24-Jul-02 20:17

24-Jul-02 20:17

I am sorry, I have been leading you down the wrong path.
You cannot import a dll in the IDL file, you can only import IDL, ODL and header files. So that will be your best bet.

You can use the importlib() directive inside of your new type library, but the MSDN documentation recommends that you use the IDL file so that all of the items from the original file will be available to your app. If you rely on the data in teh DLL, you will only get what is in the type library (which this may also include all of the items in teh dll so it wouldn't matter).

Either way I think that using the IDL file from your base project is prefectly acceptable.

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!

Any ideas on how to..

Anonymous24-Jul-02 17:38

Anonymous

24-Jul-02 17:38

I've been thinking about it... And I cant figure it out. How would a program perform a md5 checksum on itself?

I need my program to do this. Wink | ;)

The problem is.... You can only calculate the checksum after its compiled.

so i have code like this....

BYTE bRealChecksum[16] = {0xA9, 0x1E, 0xA7, 0x63,
0x0A, 0xD5, 0x55, 0x1B,
0x26, 0x80, 0xB9, 0x71,
0x9C, 0x66, 0xCC, 0xEF};

Then I calculate the checksum, then compare it to the BYTE array above which holds the real checksum, and what the results of the checksum should be. If they are not equal, the file has been modified.

But now, how am I supposed to know the checksum, without compiling? Because I need to know what the checksum of the compiled file is going to be, before I compile it.

Anyone have any ideas?

Scott H. Settlemier24-Jul-02 17:47

Scott H. Settlemier

24-Jul-02 17:47

We send out discs that have their own checksum on them...
For a simple checksum it's not so hard to compute what
value would be the checksum of a disc given a field of
known values that would change to that value and the
original checksum of the disc.. I shudder to think how
hard this would be with a respectable hash....
Yikes.
I'd be surprised if someone has an easy way to do this.

ACtually, thinking about what claims are made for MD5,
it would be practically impossible no? If the hash is
hard to work backwards to text, then it bears little
relationship to slightly modified versions of the text.
(just what you'd need to be able to implement your scheme)
Sorry. Looks like you're out of luck.

Anonymous24-Jul-02 18:15

Anonymous

24-Jul-02 18:15

Ya, I think I've decided to just store the checksum in an external file... Which is what I wanted to avoid... But seems to be the only possible way.... At least with a hash like md5 .. like you stated Wink | ;)

Daniel Lohmann24-Jul-02 22:44

Daniel Lohmann

24-Jul-02 22:44

Looks a bit like an endless recursion:

To calculate the checksum you need all bytes of the .exe which includes the checksumm... Wink | ;-)

The only way I can think of is to store the checksum in an area that is not used for creating the hash. Of course, your "MD5" hash then is not a usual MD5 hash any more, but if the app just want's to detect if it has been modified this would work.

--

Daniel Lohmann

http://www.losoft.de

benjymous24-Jul-02 22:47

benjymous

24-Jul-02 22:47

It depends if you want it hackerproof.

An easy option is just to make the checksumming code ignore the part of the file that contains the real checksum (then that can change to anything you like without modifying the actual checksum). Run this once with a blank value for that, calc the checksum, fill it in to the variable, and recompile.

Of course, this won't stop anyone else modifying the code, and fixing the checksum.

--
Help me! I'm turning into a grapefruit!

Help on multi-threading

Abin24-Jul-02 17:14

Abin

24-Jul-02 17:14

I'm studying multi-threading today and got some major problems, the biggest one is that the worker thread is not terminating as expected, my code looks like this:

// global
BOOL g_bAbort = FALSE;
UINT ThreadProc(LPVOID lpParam)
{
    while (!g_bAbort)
    {
        // DoSomething(); // do some thing
    }
    return 0;
}
  
// in some class named "CThreadTestDlg"
void CThreadTestDlg::OnStart()
{
    // begin the thread
    g_bAbort = FALSE;
    m_pThread = ::AfxBeginThread(ThreadProc, NULL);
}
  
void CThreadTestDlg::OnStop()
{
    // wanna stop the thread...
    g_bAbort = TRUE;
    DWORD dwExitCode = 0;

    do
    {
        Sleep(200);
        ::GetExitCodeThread(m_pThread->m_hThread, &dwExitCode);
    } while (dwExitCode == STILL_ACTIVE);
}

OnStart() is called as soon as the program starts, OnStop() is called when a button captioned ""stop" is pressed.

I press the "stop" button and my program freezes. I used debugger and found out that the thread never ended, even though g_bAbort has been set to TRUE. Why so?

Thank you a lot.

Scott H. Settlemier24-Jul-02 17:40

Scott H. Settlemier

24-Jul-02 17:40

CWinThread normally has m_bAutoDelete set TRUE which
means it will delete itself and close the m_hThread
handle upon termination. You should either reset the
m_bAutoDelete flag and delete it yourself or else use
DuplicateHandle to create your own copy of the m_hThread
handle which will be valid in your OnStop function.

Abin24-Jul-02 17:43

Abin

24-Jul-02 17:43

But the thread did not terminate, the "exit code" is always STILL_ACTIVE.

Scott H. Settlemier24-Jul-02 17:52

Scott H. Settlemier

24-Jul-02 17:52

What's the return value of GetExitCodeThread?

Abin24-Jul-02 18:15

Abin

24-Jul-02 18:15

It returns TRUE, and the exit code keeps being STILL_ACTIVE even though I had set g_bAbort to FALSE already.

Peter Occil24-Jul-02 18:14

Peter Occil

24-Jul-02 18:14

In the OnStart handler, you should start the thread, then loop the PeekMessage function until the thread exits or the user presses STOP.

void CThreadTestDlg::OnStart(){
 // begin the thread
 MSG msg;
 DWORD threadec;
 g_bAbort = FALSE;
 m_pThread = ::AfxBeginThread(ThreadProc, NULL);
 while(::PeekMessage(&msg,NULL,0,0,PM_REMOVE)){
  // process any messages while the other thread does background
  // processing
  if(msg.message==WM_QUIT){ // quit this thread.
   // Add code to break the other thread here.
   ::PostQuitMessage(msg.wParam);
   break;
  }
  ::TranslateMessage(&msg);
  ::DispatchMessage(&msg);
  if(!::GetExitCodeThread(m_pThread->m_hThread,&threadec))
   return;
  if(threadec!=STILL_ACTIVE)break;
 }
}

I apologize it this isn't right; I'm much used to programming in C.

Peter O.

RichardWdy24-Jul-02 18:20

RichardWdy

24-Jul-02 18:20

I think you should do like this...
void CThreadTestDlg::OnStop()
{
// wanna stop the thread...
g_bAbort = TRUE; DWORD dwExitCode = 0;
}
Thus you can abort the thread.

No pains, no gains.