|
What about compiling statically?
-Jack
To an optimist the glass is half full.
To a pessimist the glass is half empty.
To a programmer the glass is twice as big as it needs to be.
|
|
|
|
|
It's not a source code issue. The winproc for the richedit window class is in the riched20.dll file. Therefore that file needs to be present and the window class registered for you to be able to use the rich edit control.
Cheers,
Tom Archer
Author, Inside C#
A total abstainer is one who abstains from everything but abstention, and especially from inactivity in the affairs of others.
|
|
|
|
|
So compiling statically in windows doesn't compile shared libs into your binary as it does in unix? Or am I missing something?
-Jack
To an optimist the glass is half full.
To a pessimist the glass is half empty.
To a programmer the glass is twice as big as it needs to be.
|
|
|
|
|
Not system files. It would be a HUGE mistake. You don't want system files in your executables. Not only would it mean that you would have to build a special version for each OS, but it would also mean a special version for each SP.
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?
|
|
|
|
|
[Edited to be half-way intellible once I had a coke in me]
It wouldn't matter anyway as user applications don't link with the libraries that contain the control code (e.g., commctrl, riched, etc.) The issue is that Windows needs to load the control's encapsulating library in order to associate the window class name (passed to CreateWindow) to the window's winproc.
Cheers,
Tom Archer
Author, Inside C#
A total abstainer is one who abstains from everything but abstention, and especially from inactivity in the affairs of others.
|
|
|
|
|
I rewrote my first response to you as upon re-reading it, I found it barely intelligible. I should never write anything before my first coke. 
Cheers,
Tom Archer
Author, Inside C#
A total abstainer is one who abstains from everything but abstention, and especially from inactivity in the affairs of others.
|
|
|
|
|
- A static (or object) library is an OBJ that is linked in with your application. This file contains the actual implementation of the code. When you select the link statically with MFC, you are including the MFC static link libaries into your build.
- Like static libraries, import libraries are used by the linker to resolve function calls. However, unlike static libraries, import libraries contain no code. Instead, import libraries contain information that helps Windows load and resolve (non-static) function calls at runtime.
As an example, let's say you make a call to CreateWindow in your code. In order for this to compile, you must have that function declared somewhere. This is take care of with the inclusion of the windows.h header. Now for the application to link, you must either include an object library (static library) that contains the actual CreateWindow function or you must provide an import library that contains the information that is needed to load the DLL containing the function at runtime. For this particular function, you would always use an import library as you would never want to statically link to the system libraries. - The last way to use a library is dynamically. To do this a DLL is loaded via the LoadLibrary function and functions are resolved via calls the GetProcAddress.
Now the case of the richedit control (housed in the riched20.dll). When you use the CRichEditCtrl, you are simply using a class that wraps the RICHEDIT window class. In order for you to resolve to the CRichEditCtrl member functions you will either statically link to the MFC or dynamically link to the MFC. However, that's not all you have to do because at this point you're only making the compiler and linker happy with regards to calls to a C++ class. This has nothing to do with the underlying window.
When you create a window, you do so by calling the CreateWindow function and passing a window class. In the case of the rich edit control, this value is "RICHEDIT". When you do that, Windows will look at an internal table and see if it any code has registered a window with the name of "RICHEDI". If so, your CreateWindow succeeds (assuming the other params are corred). If not, it fails.
But how does Windows know if a Window is "registered" or not and what does that mean? If you have installed the riched20.dll, upon its loading by Windows, that DLL will call the RegisterWindow function. That function is specifically meant to associate a window class name with a winproc.
Now, if you call the CreateWindow function on a system where the riched20.dll has been installed, Windows already has loaded the DLL and the winproc function needed in order to send messages to that window (such as WM_CREATE).
Therefore, distributing the actual rich edit window code is a completely different issue than how you link with the MFC in order to use the CRichEdit class.
Cheers,
Tom Archer
Author, Inside C#
A total abstainer is one who abstains from everything but abstention, and especially from inactivity in the affairs of others.
|
|
|
|
|
Very informative, thank you.
Like I said before, I wasn't sure how windows would handle this. I was speaking from my unix experience. In unix if you are to include a library like PCRE (Perl Compatible Regular Expressions) for example, If you link normal the person running your binary has to have PCRE on their system, if you use the -static flag it compiles all the code in (resulting in a much larger binary) and you don't have to worry about your users having PCRE at all. I assumed windows would work similar.
-Jack
To an optimist the glass is half full.
To a pessimist the glass is half empty.
To a programmer the glass is twice as big as it needs to be.
|
|
|
|
|
Jack Handy wrote:
Like I said before, I wasn't sure how windows would handle this
No problem. That's why into a bit of detail.
Cheers,
Tom Archer
Author, Inside C#
A total abstainer is one who abstains from everything but abstention, and especially from inactivity in the affairs of others.
|
|
|
|
|
Hello.
I have having trouble getting a program to restore the the location of the splitter bar in a program with splitter views (two).
Here is the code in main.
-----
BOOL CMainFrame::OnCreateClient(LPCREATESTRUCT lpcs, CCreateContext* pContext)
{
CString version = _T("1.0");
if (!m_wndSplitter.CreateStatic(this, 2, 1) ||
!m_wndSplitter.CreateView(1, 0, RUNTIME_CLASS(CView2),
CSize(0, 0), pContext) ||
!m_wndSplitter.CreateView(0, 0, RUNTIME_CLASS(CView1),
CSize(0, MyApp.GetProfileInt(version, _T("Size"), 300)), pContext))
return FALSE;
return TRUE;
}
The progres saves the size of the window in the register. Everything looks okay and function well except for the splitter. Here is the program design.
- program first starts with default View1 at height 300 (Note: I created view2 first for UpdateAllViews() to work right similar what Prosise presents in his book).
- progres restores size of view1 via code above.
Again, I cannot see a flaw in the code unless there is a flaw somewhere in the design. I implement the same code Prosise presents in his book to return windows size and location. Here is the code that does that.
-----
if (!(reinterpret_cast<cmainframe *="">(m_pMainWnd))->RestoreWindowState())
m_pMainWnd->ShowWindow(m_nCmdShow);
-----
Is it possible that this code and the one to restore size of view1 are conflicting?
Again, I am open to all interpretations and if you have a better technique please show.
Thanks,
Kuphryn
|
|
|
|
|
I've found that I needed to make a call such as the following to get this to work.
<br />
m_SplitterWindow->SetColumnInfo(0, splitX, 0);<br />
I do this after calling CreateView(). Hope this helps!
swinefeaster
Check out Aephid Photokeeper, the powerful digital
photo album solution at www.aephid.com.
|
|
|
|
|
Thanks!
Another member posted the same solution at CodeGuru. I will implement it soon. I am working on a major multithread bug right now.
Kuphryn
|
|
|
|
|
Hi.
Where should I add the functions SetColumnInfo() such that when the program starts up it will remember the size of each pane? Do I need to override a function and add SetColumnInfo()?
You including "splitx." What is that for?
Thanks,
Kuphryn
|
|
|
|
|
I'm assuming you do have the msdn help installed? Do an index search for SetColumnInfo().
splitx is the width of the slitter pane i want to start off with.
swine
Check out Aephid Photokeeper, the powerful digital
photo album solution at www.aephid.com.
|
|
|
|
|
Here is the solution in RestoreWindowState() functon.
A special thanks to members of CodeGuru and CodeProject for responding about function SetColumnInfo() and RecalcLayout().
-----
bool CMainFrame::RestoreWindowState()
{
m_bVeriReturn = false;
CString version = _T("1.0");
WINDOWPLACEMENT wp;
wp.length = sizeof(WINDOWPLACEMENT);
GetWindowPlacement(&wp);
if (((wp.flags = theApp.GetProfileInt(version, _T("flag"), -1)) != -1) &&
((wp.showCmd = theApp.GetProfileInt(version, _T("command"), -1)) != -1) &&
((wp.rcNormalPosition.bottom = theApp.GetProfileInt(version, _T("bottom"), -1)) != -1) &&
((wp.rcNormalPosition.left = theApp.GetProfileInt(version, _T("left"), -1)) != -1) &&
((wp.rcNormalPosition.right = theApp.GetProfileInt(version, _T("right"), -1)) != -1) &&
((wp.rcNormalPosition.top = theApp.GetProfileInt(version, _T("top"), -1)) != -1))
{
wp.rcNormalPosition.left = min(wp.rcNormalPosition.left,
::GetSystemMetrics(SM_CXSCREEN) - ::GetSystemMetrics(SM_CXICON));
wp.rcNormalPosition.top = min(wp.rcNormalPosition.top,
::GetSystemMetrics(SM_CYSCREEN) - ::GetSystemMetrics(SM_CYICON));
SetWindowPlacement(&wp);
m_nSplitSize = theApp.GetProfileInt(version, _T("topsplit"), 300);
m_wndSplitter.SetRowInfo(0, m_nSplitSize, 10);
m_wndSplitter.RecalcLayout();
m_bVeriReturn = true;
}
return m_bVeriReturn;
}
-----
Kuphryn
|
|
|
|
|
I have been getting access violations lately. To fix it all I have to do is delete all the object files in the Debug\ directory and recompile. After doing this everything works fine. My question is, Is this normal? Does this happen to other people too or do I have another problem that needs addressing?
-Jack
To an optimist the glass is half full.
To a pessimist the glass is half empty.
To a programmer the glass is twice as big as it needs to be.
|
|
|
|
|
From what you're describing your dependencies are out of whack. This is generally solved by doing a Rebuild All (or delete all binaries and Build as you did). However, you need to find out why an incremental build is not building the binaries that need to be built for the app to run. I know this isn't a complete answer, but maybe it will help you in terms of looking in a given direction.
Cheers,
Tom Archer
Author, Inside C#
Please note that the opinions expressed in this correspondence do not necessarily reflect the views of the author.
|
|
|
|
|
Thanks.
Now that I know it isn't normal I will look into solving it. Just incase it proves to be a hard solution, Is there a problem besides being annoying with the method I have been using?
-Jack
To an optimist the glass is half full.
To a pessimist the glass is half empty.
To a programmer the glass is twice as big as it needs to be.
|
|
|
|
|
Jack Handy wrote:
Now that I know it isn't normal I will look into solving it. Just incase it proves to be a hard solution, Is there a problem besides being annoying with the method I have been using
No. It's just a pain (in terms of time) to have to rebuild all the time. However, it certainly doesn't hurt anything.
Cheers,
Tom Archer
Author, Inside C#
Please note that the opinions expressed in this correspondence do not necessarily reflect the views of the author.
|
|
|
|
|
Jack this definitely isn't normal. In fact I've never seen anything like this and I work in VC++ a zillion hours a day, every day. It sounds like an out and out problem which is only randomly rearing its head, and doing a clean build makes it *appear* to go away.
Is the violation address consistent? If you are using a lesser version of Windows (not NT,2K,XP), then once something like this happens it can continue to happen until you reboot. Try and run your app under the Debugger at all times, then when you have a problem like this you can step right in and hopefully track it down. It could be a pointer which isn't pointing anywhere valid. If you have exception handling code in your app you should be picking up most if not all problems like this.
Neville Franks, Author of ED for Windows. www.getsoft.com
|
|
|
|
|
Hmmm, so you don't agree with Tom? (see above) Because that was along the lines of what I was thinking.
-Jack
To an optimist the glass is half full.
To a pessimist the glass is half empty.
To a programmer the glass is twice as big as it needs to be.
|
|
|
|
|
I agree with Neville. It looks like there may be something awry in your code.
/ravi
"There is always one more bug..."
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
Hmmm, so you don't agree with Tom? (see above) Because that was along the lines of what I was thinking.
-Jack
To an optimist the glass is half full.
To a pessimist the glass is half empty.
To a programmer the glass is twice as big as it needs to be.
|
|
|
|
|
Jack Handy wrote:
Hmmm, so you don't agree with Tom? (see above) Because that was along the lines of what I was thinking.
Tom wrote:
However, you need to find out why an incremental build is not building the binaries that need to be built for the app to run.
I certainly agree with this, but in my experience VC doesn't get this wrong as long as you've got the project and it's dependencies set up correctly.
If you do a Rebuild All and then it happens again and none of the dependant code has changed, then me thinks it must be a problem in your code.
Neville Franks, Author of ED for Windows. www.getsoft.com
|
|
|
|
|
Neville Franks wrote:
If you do a Rebuild All and then it happens again and none of the dependant code has changed, then me thinks it must be a problem in your code.
It only happens if I do a normal build (F7) but is fine after I rebuild all.
-Jack
To an optimist the glass is half full.
To a pessimist the glass is half empty.
To a programmer the glass is twice as big as it needs to be.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
