|
Dominik Reichl wrote:
No way to do this any more???
Not like that. That's DOS. Depending on your target platform, you'll probably have to go through the API. And I couldn't tell you where to begin looking for the solution in MSDN.
You could, however, start here[^].
J
May the bear never have cause to eat you.
|
|
|
|
|
Of course you could just do this:
system("subst q: \myfiles");
J
May the bear never have cause to eat you.
|
|
|
|
|
Hello, everyone.
Precursor:
I've developed in Visual C++ 6.0 for a while and now I'm developing in Embedded Visual C++ 3.0 for handheld devices. One of the pecular behavioural patterns, or rather, differences, between 6 and 3 is the auto-inclusion of MESSAGE_MAPping through to a control placed on a dialog. This also leads to the inability of 3.0 to allow member variables to be generated through the Class Wizard.
Which leads me to my question:
A) Where can I learn (through an on-line tutorial) about how the MESSAGE_MAPping works so I can enable dialog controls on my dialog without manually '#define'ing every dialog control by hand? (Or, at least, if I must do it by hand, what is the best method to perform such tasks.)
I'm also adding, as a member variable, a CListBox object and calling m_myListBox.Create(...rect,IDC_MYLISTBOX) to actually have a list box on the dialog. The intesting thing is this: 'IDC_MYLISTBOX,' on the dialog, in not visible. I only need the IDC_MYLISTBOX value for my create routine and after Create returns, I have a listbox. (Values added later through code.) If I delete the control from the dialog, the program bombs because EVC++ 3.0 needs its reference number from the resource file.
I'd, truely, rather not include a list box control on the form and then hide it and *then* call create on a member variable of type CListBox. Does that make sense to you?
B) Should/Can I write in my own function maps through the MESSAGE_MAP routines of my classes when such class behaviour should be associated with a dialog control?
C) Are there any sites primarily associated toward developing hand held devices?
I hope my questions make sense. I know that in 6.0 it is bad Ju-Ju to toy-around in the MESSAGE_MAPs.
I've a dozen more questions with this topic/EVC++ 3.0 but I'll hold them for the moment. Thanks!
|
|
|
|
|
y ! FAQ's?
~CodeTheDreams~
|
|
|
|
|
Thanks for the reply but it is a little vague.
Are you talking about the Mike Dunn's C++ FAQs on this website? If not, where?
|
|
|
|
|
I have a project, with a single executable and several dll's. I created an 'data carrier' object to pass information from one dll to another. I tried to place this object in a static library (.lib) and then link the executable and all dll's to this lib. However, when I do this I get access violation when accessing an object that was created by another dll. Therefore i moved the object to my executable, exported it and linked all my dll's to the lib of my executable. This seemed to work. But after some serious testing I still sometimes get access violations or dbg heap errors.
I did the same thing with other objects, and those do not (seem to) give any problem. The only difference I can find is that I use 2 members in the object that use templates.
Does anyone know a solution for this problem? I'm really running out of ideas.
|
|
|
|
|
1. Read (carefully) MSDN: key words "__declspec(dllexport)" and "__declspec(dllimport)"
2. Use Wizard to create a simple DLL, check both sample code and exports. See how it is supposed to be done.
|
|
|
|
|
I did use the declspec export and import as shown by the examples. I even used a .lib, which exports everything. Still nothing.
|
|
|
|
|
Did you explicitly export you template data types (using typedef etc..)?
Is the memory model the same for all of your modules (lets say /MT with 8 byte alignment)?
|
|
|
|
|
I used /MD everywhere, and I exported the template data types, but I did not use a typedef... what would a typedef add ?
|
|
|
|
|
I had:
void CSearchView::OnButton1()
{
CRuntimeClass* pViewClass = RUNTIME_CLASS( <code>CBKView </code>);
if ( pViewClass == NULL ) return;
CMultiDocTemplate* pTemplate = theApp.m_pView1Template;
if ( pTemplate == NULL ) return;
((CMainFrame*)AfxGetMainWnd())->SwitchView( pTemplate, pViewClass );
}
and forgot to include BKView.h in the file, so I got:
C:\ATRAIN2\ASampleProjects\ZOrder SWITCH CENTERVIEW\SearchView.cpp(76) : error C2653: 'CBKView' : is not a class or namespace name
I understand the above error, but...
So I put in the line
#include "stdafx.h"
#include "BK.h"
#include "SearchView.h"
<code>#include "bkview.h"</code>
#ifdef _DEBUG
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif :
and I'm getting:
SearchView.cpp
c:\atrain2\asampleprojects\zorder switch centerview\bkview.h(28) : error C2143: syntax error : missing ';' before '*'
c:\atrain2\asampleprojects\zorder switch centerview\bkview.h(28) : error C2501: 'CBKDoc' : missing storage-class or type specifiers
c:\atrain2\asampleprojects\zorder switch centerview\bkview.h(28) : error C2501: 'GetDocument' : missing storage-class or type specifiers
Error executing cl.exe.
pointing to :
public:
CBKDoc* GetDocument();
Appreciate your help,
ns
|
|
|
|
|
u didnt include in ur BKView.h what a CBKDoc is
Papa
while (TRUE)
Papa.WillLove ( Bebe ) ;
|
|
|
|
|
I see what you mean. But check this out:
BEfore I had my CSearhView class, and I just ran stuff created by VS by default, things ran fine. I note that "bkdoc.h" was automatically included in the .cpp file.
SO after I made my SearchView filkes, neither the .cpp nor the .h files had the doc.h file in it. For some reason I didnt rememeber this omiission by VS in my past (first ) project.
But its compiling now. SO I thank you very very much!
Appreciate your help,
ns
|
|
|
|
|
Papa
while (TRUE)
Papa.WillLove ( Bebe ) ;
|
|
|
|
|
It didn't add the "doc.h" files to the new view because the new view isn't automatically associated with the existing document class. Another thing you must do, to avoid errors, is include the inline call "GetDocument" in the CSearchView header file (you can find the current GetDocument in the BKView header), and also, include the non-inline version of GetDocument in the CSearchView source file (both versions have #ifdef _DEBUG around them).
What will happen if you don't do this and you call GetDocument from CSearchView, you will end up getting a pointer that doesn't point to the correct object, and you won't be able to correctly access the document's data.
Chris Richardson
Programmers find all sorts of ingenious ways to screw ourselves over. - Tim Smith
|
|
|
|
|
Hey! Thank you so much for this preventive measure. In my experience so far (meager) I hadnt called the doc pointer from anywhere but the view, but now I am armed with this knowledge!!! MAny many thanks!
Appreciate your help,
ns
|
|
|
|
|
Well,
#including the doc.h in the searchview.h resolved that issue that I posted about initially (and I also noted that putting the doc.h in the COriginalView.h took care of it just as well instead)
Next I wanted to get the COriginalView pointer in the mainframe class, and put in the OriginalView.h file into mainfrm.cpp, it gave me the exact same errors I had gotten when earlier when I had added the OriginalView.h to SearchView.h. The earlier issue had I resolved by putting in the missing ingredient - the doc.h file into the searchview.h file. But this time, I couldnt appease it by putting doc.h into the mainfrm.h. I had instead to add the doc.h to the OriginalView.h.
SO it seems that the best resolution here for both problems is to put the include doc.h into the COriginalView.h file, and nnot the in the files where I #include COriginalView.h
WOuld you agree?
Thanks
Appreciate your help,
ns
|
|
|
|
|
I think the best solution (personally), is to put doc.h in any source file that you use the any of the view classes in. Just make sure you include doc.h before you include any of the view header files. So, in MainFrm.cpp, we'll have this:
..other things ommitted..
#include "doc.h"
#include "OriginalView.h"
#include "SearchView.h"
And in SearchView.cpp, we'll have this:
..other things ommitted..
#include "doc.h"
#include "SearchView.h"
#include "BKView.h"
If you are trying to store a pointer to the view class in the main frame class, then in MainFrm.h, just have this:
class CSearchView;
class COriginalView;
class CMainFrame : public blah blah blah...
Hope it helps (but if it doesn't, feel free to ask more questions ),
Chris Richardson
Programmers find all sorts of ingenious ways to screw ourselves over. - Tim Smith
|
|
|
|
|
Ah!! You know what I was doing wrong? I didnt put the doc.h before the view.h include!!!!
Now it works!!!! I didnt think the order mattered, but it makes sense because the compiler reads in the whole file literally when it sees a #include I gather.
Appreciate your help,
ns
|
|
|
|
|
ns wrote:
I didnt put the doc.h before the view.h include
Uh oh
Yeah, the order is very important. The preprocessor transforms the source file and all it's included files (minus #ifndef'd out sections etc) into one big file (not sure on the actual storage of it), then the compiler compiles that. So if you don't include doc.h before the view class, this is what the compiler sees:
class CYourView : public CView
{
...
CYourDoc * GetDocument();
};
class CYourDoc : public CDocument
{
...
};
And that's what caused your problems. Glad to hear that you fixed it!
Chris Richardson
Programmers find all sorts of ingenious ways to screw ourselves over. - Tim Smith
|
|
|
|
|
I'm reading <<programming applications="" for="" microsoft="" windows="">>, and get confused by some point.
The following is quoted from :
"every process has its own private address space. Process A can have a data structure stored in its address space at address 0x12345678, while Process B can have a totally different data structure stored in its address space—at address 0x12345678. When threads running in Process A access memory at address 0x12345678, these threads are accessing Process A's data structure. When threads running in Process B access memory at address 0x12345678, these threads are accessing Process B's data structure. Threads running in Process A cannot access the data structure in Process B's address space, and vice versa."
my questions are:
1> 0x12345678 appears in both process A and B. is
0x12345678 the actual virtual address or just the offset
to the base virtual address of a process?
2> if the answers to the first question is "actual virtual
address", does that mean two processes could have the
same virtual address(or overlapped virtual address, in
other words)?
2> how does the system raise a Access Violation exception?
in particular, is the exception raised by checking the
virtual address against the process's address space or by
checking it against the phisical address after address
translation?
Thank you very much!
Wenrich
|
|
|
|
|
You kind of complicate the issue (not without the help of the good book ).
Virtual address could be understood as mapped address. This mapping service provided by the system so it is transparent to the program. Each process has right to use up to 2GB in Win9X and 4GB in WinNT (I could be wrong on the actual numbers but that is irrelevant). Obviously very few computers have that much memory, so system uses swapping to load requested memory block into the physical memory. If application ask for memory at 1GB offset it does not mean that it actually offset to the physical memory. The physical address of the memory block could be changed during lifetime of the program. The virtual address stays the same, because, once again it is just mapping for the system to know what a program is asking.
|
|
|
|
|
Thanks a lot!
I'm aware of the virtual memory and physical memory concepts. I just got
confused by the statement that process A and process B both have acess to virtual memory at 0x12345678, because my understanding is that the system
uses the virtual memory space allocated to the process to verify whether a memory access is valid and an Access Violation would be raised if it's not.
Is my understanding wrong?
Thank you very much for your help!
Wenrich
|
|
|
|
|
I want to draw a line/rectange(normal CPaintDC functions) in a Dialog?
|
|
|
|
|
Add a handler for the WM_PAINT message (OnPaint) and have a blast.
Regards,
Alvaro
All you need in this life is ignorance and confidence, and then success is sure. -- Mark Twain
|
|
|
|