|
Is there any way to find out the directory that the progam is running out of?
I have found out how to get the current working directory, but this is not what I want because if the user changes directories, the current working directory changes with it. I want to be able to have these extra files in the directory that my program is running out of.
I have done this:
BOOL CSetupModeless::OnInitDialog()
{
int drive, maxLength;
maxLength = 100;
drive = _getdrive();
static char path[100];
_getdcwd(drive,path,maxLength);
//...
}
but that doesn't give me the desired results.
|
|
|
|
|
GetModuleFileName[Ex]() will do it.
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
Ok, now it seems to recognize that the extra files are there... But, for example, after a user "opens" a file, no matter how much info I write into any of the extra files I have, they always end up remaining empty. The write operation seems to be doing what it's supposed to be doing, but I don't understand why the files are still empty after writing. If the user doesn't "open" a file, any information written to the extra files does, in fact, get written to the files (and remains in the files after program execution)
|
|
|
|
|
SDI = single document, which means only one file is open at any given time. As for other non-document files that the program needs, use as many as is necessary.
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
I have created a dialog that is rendered into by an OpenGL RC.
Now that I have that going I'd like to be able to add a few control variables.
What I'd like to do is set OpenGL to only render into a portion of the dialog..... I was wondering how I'd go about this, do I have to create another window in the dialog?
If so, what type is appropriate, I'm only getting started with MFC.
A quick aside, in my OnPaint() I call the base OnPaint() function and THEN render my scene, yet the OK and CANCEL buttons still get painted. Shouldn't they be painted over by RC?
|
|
|
|
|
I would create a picture control inside the dialog and assign a CStatic control variable to it, say m_cPic. Then in OnInitDialog you can get a DC for the picture control and assign this DC to the OpenGL rendering context. Something like
HDC hdc = m_cPic.GetDC()->GetSafeHdc();
wglMakeCurrent(hdc, hGLRC); // hGLRC is handle to the OpenGL rendering context
This approach worked for me before.
|
|
|
|
|
Thanks I'll give it a go.
Is any special cleanup necessary if you use this approach?
|
|
|
|
|
You should release the device context hdc using ::ReleaseDC API function
|
|
|
|
|
ComboController wrote:
A quick aside, in my OnPaint() I call the base OnPaint() function and THEN render my scene, yet the OK and CANCEL buttons still get painted. Shouldn't they be painted over by RC?
You window gets its OnPaint() first because its at the back of the TAB or window order. The OK/Cancel buttons gets theirs after the dialogs OnPaint(), so they would appear over your scene.
On a second not, when your added your own OnPaint() function for your dialog, you would have seen a comment such as:
<br />
This is a bad thing to do, as the CDC parameter passed through to the OnPaint() handler gets setup in some way by the system, so what your doing could crash/corrupt things. If you can, see if you can avoid calling the base class function in this way.
Roger Allen
Sonork 100.10016
Were you different as a kid? Did you ever say "Ooohhh, shiny red" even once? - Paul Watson 11-February-2003
|
|
|
|
|
There is a lot of stuff in there to help you.
http://pws.prserv.net/mfcogl/
Mykel
Everything's beautiful if you look at it long enough...
|
|
|
|
|
In VS.NET 2003 or VS 6, I was curious where "main" or "wmain" or "_tmain" or "winmain" are defined as the starting point of applications? (i.e. which file?) I ran a search and I found a few, but I thought they would be in some crt file but that wasn't the case...any ideas?
thanks
|
|
|
|
|
I'm not sure myself, but if I wanted to know I'd debug an app by pressing F11 (Step Into) instead of F5. This breaks at the first line of the program, giving you the name of the file where "main" is located.
Regards,
Alvaro
Hey! It compiles! Ship it.
|
|
|
|
|
It depends totally on the type application. In console applications you define main yourself.
John
|
|
|
|
|
actually I think my question wasn't clear enough..for instance, why is it that a compiler like VS.NET knows that main and _tmain can be used as starting points to a console application? where is the setting that tells itthat..I remember reading a book that stated some of this stuff are in the crt files, but just can't remember which crt file
thanks
|
|
|
|
|
...\VC98\MFC\SRC\APPMODUL.CPP
|
|
|
|
|
as far as i know these functions are defined by the linker!
you can overwrite this setting by adding "/ENTRY: new_main" to the linker command line!
(make sure that your new_main doesn't have any parameters!)
|
|
|
|
|
this guy knows his stuff ^ 
|
|
|
|
|
Can you pass arguments from a member function to another member function in a different class?
Such as data from a tree class to a linked-list class.
Hmm. Mine is getting passed but does not want to be inserted in the list.
|
|
|
|
|
Sirrius wrote:
Can you pass arguments from a member function to another member function in a different class?
Yes.
Sirrius wrote:
Mine is getting passed but does not want to be inserted in the list.
You'd have to provide a code snippet of the offending code for any further help.
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
Here is the List class code.
#include <iostream>
#include <string>
#ifndef LIST_H
#define LIST_H
using namespace std;
struct node
{
string data;
node *next;
};
//Linked List class
class List
{
node *first;
public:
List()
{
first=NULL;
}
void insertNode(string newName)
{
node *p;
cout << newName << endl; //cout for debugging.
p=new node;
p->data=newName;
p->next=first;
first=p;
}
void outputList(ostream &out)
{
node *p;
p=first;
if(!empty())
{
while(p!=NULL)
{
cout << p->data << endl;
p=p->next;
}
}
else
cout << "The list is empty!" << endl;
}
bool empty()
{
if(first==NULL)
return true;
else
return false;
}
};
#endif
|
|
|
|
|
Ok, so where's the example of "passing arguments from a member function to another member function in a different class?"
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
Okay, this code is from the tree class. It is supposed to do an in-order traversal of the tree and send the data to the List::insertNode function. It seems that it is being sent because my cout line is outputing it in the insertNode function.
Should I send the entire code?
void output(ostream &out) //From class treeNode
{
List l;
//treeNode *p;
if(smaller!=NULL)
smaller->output(cout);
//out << name;
l.insertNode(name);
if(bigger!=NULL)
bigger->output(cout);
}
|
|
|
|
|
Anonymous wrote:
It seems that it is being sent because my cout line is outputing it in the insertNode function.
Ok, so what seems to be the problem. If treeNode::output() is calling List::insertNode() and cout is outputting, I don't see the problem.
The one thing that might be an issue is that variable 'l' is local to the output() function and with each recursive call, a new List object is created. As the recursive calls unwind, those local variables lose scope and go away.
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
Oh my, I didn't even think of that. haha. That makes sense to, about what you said about the variable l. Because until you mentioned that, I thought everything straight and didn't give that l an ounce of thought.
I will see if I can tinker with that a little and make something happen. Thanks for your sharp eye.
Brian.
|
|
|
|
|
[edit] found it - passed the wrong thingie as LPARAM. I feel so dumb, I even wish I would have used hungarian notation...[/edit]
Hi,
I'm using a virtual listview which, according to the docs, can manage selection + focus state (yippee).
However, when I send LVM_SETITEMSTATE to change the state, thing behave queer.
Moving selection+focus from one item to the next does:
- keep focus on old one
- old item has "greyed selection" (as if the lc is not selected)
- new item gets blue "selected" bar
- clicking around moves the "greyed" selection bar as usual, but the blue selection bar of the new item remains as is
LVC is: OWNERDATA, LVS_EX_FULLROWSELECT, LVS_SHOWSELALWAYS, and allos multiple selection
(single selection doesn't work better)
Anybody knows that?
"Dor säggsische Dialeggt eechnet sich wie keeen onderor für den Ausdrugg zäärdlischor Gefiehle."
sighist | Agile Programming | doxygen
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
