|
Hello All,
This is important, atleast for me  So any hints will be usefull.
I have my App as a SDI, With the CFormView as the base class of the view class. the problem is this,
when maximize the Main App window (to fill the screen) the Form doesn't get resized to fill the App main window, but it stays at its original size and location.
I was wondering if there is a way to get the view form (dialog) gets resized to fill the App main window when I maximize the App window, and to Get it to be resized to fill the App window if I resized the App.
Basically I want the View Form to occupy the App Main window at all times.
Thanks in advance.
Fady.
|
|
|
|
|
Hey,
I know I saw a resizable FormView around here some where, maybe it was at CodeGuru. Anyway, you could modify one of the Resizable dialog classes to suit you need.
Here is one:
http://www.codeproject.com/dialog/resizabledialog.asp
-Ben
---------
On the topic of code with no error handling -- It's not poor coding, it's "optimistic" 
|
|
|
|
|
Hello All,
I have a quick question, you know Al know the "File Sharing Violation" error (i.e. when you try to delete a file that is in use).
The Question is this, I'm trying to write an application that I give it this filename, and it tells me who, or what is using this file.
So I was wondering if there is a way (MFC or a Win32 API ) that can accomplish this
Thanks in Advance
Fady
|
|
|
|
|
Hi, I have a design I am considering implementing and I was wondering if I could get some feedback on it.
Basically I am considering implementing a refcounting scheme (nothing too difficult there) as well as an instantiation techniques that works as follows:
All classes that need to be allocated on the heap will have a virtual method called init(). init() provides a common place to initialize variables, etc.
All classes provide a static method called create() that returns a new instance of the class. the create() method should mirror the constructor for the class as it will call this constructor when creating a new instance for the class. Example:
class Foo {
Foo();
Foo( int count );
static Foo* create() {
Foo* result = new Foo();
result->init();
return result;
}
static Foo* create( int count ) {
Foo* result = new Foo( count );
result->init();
return result;
}
};
This allows for virtual init function to be called, allowing single step creation, which is convenient for many kinds of classes, at least in what I am working on, so the syntax is now the following for creating things on the heap:
Foo* f = Foo::create();
instead of
Foo* f = new Foo();
The base class would provide addRef(), release(), and getRefCount() for performing refcounting.
The base class would also have two more functions. A protected virtual function called destroy() that would contain common termination code. Another public method called free() that would call destroy() and then delete this to destroy the object. the release() method would call free() (instead of delete this) when the refcount dropped to 0. So to completely destroy an object on the heap where you "own" that object (i.e. an object that doesn't get used by anyone else but the class instantiating it) you would do the following:
Foo* f.... //stuff happens
//later on...
f->free();
To simply release the object the sfollowing syntax is used:
f->release();
The advantage (or at least what I am thinking is the advantage), is the ability to have a common virtual function for both initialization ( init() ) and clean up ( destroy() ) that will safely get called, since constructors and destructors cannot call virtual functions in their implementation (well they can, they just don't behave like you'd expect them ).
In addition, a ref counting scheme is in place to allow potential COM features in the library.
Hope all this is reasonably clear, and I look forward to any feedback ( even if you think I am flat out crazy  )
|
|
|
|
|
|
no - good point, I suppose it should be protected
|
|
|
|
|
I'm also not sure why do you need free() function. Isn't virtual destructor enough? I'm fully aware that virtual functions are called non-virtually from d'tor, but can't see any serious issue here. Do you expect problems related to the order of destructor calls?
Tomasz Sowinski -- http://www.shooltz.com.pl
|
|
|
|
|
Normally I'd agree with you but I have some stuff that needs to have virtual clean up methods that need to be called prior to the destructor to work right. That is the idea behind the free() call, a single place where the virtual clean up methods can get called prior to the destructor, sort of like the FinalConstruct()/FinalDestruct() of ATL.
|
|
|
|
|
> no - good point, I suppose it should be protected
So it doesn't have to be virtual... Note that you're always dealing with object of type Foo in Foo::create:
static Foo* create( int count )
{
Foo* result = new Foo( count );
result->init(); //calls Foo::init even if init isn't virtual
return result;
}
In fact, if you don't have two or more versions of Foo::create, you could place all init functionality inside create.
Personally, I'd move the parameters from the constructor to non-virtual init:
static Foo* create( int count )
{
Foo* result = new Foo();
result->init(count);
return result;
}
The only thing that constructor does in this scenario is initializing vtable pointer (this of course is done automatically for you). 'Real' init would be performed in init() itself.
Tomasz Sowinski -- http://www.shooltz.com.pl
|
|
|
|
|
Well the init function is virtual so that base class initialization will take place in one common place. No arguments are needed for it - the constructor will initialize member variables (set pointers to NULL, etc )and then init does the rest. All classes will be a part of a single rooted hierarchy.
|
|
|
|
|
Sorry, but it doesn't matter if init is virtual or not. You will have to explicitly call base::init in derived::init. Virtualness has nothing to do with it.
Tomasz Sowinski -- http://www.shooltz.com.pl
|
|
|
|
|
in your implementation of init() yes, I understand that, what I was referring to was the desired behaviour of being able to create and instance of some object and then call init() on that object, all in the constext of a ::create() call. This would then chain all the functionality together in the virtual init()'s.
|
|
|
|
|
> This would then chain all the functionality together
> in the virtual init()'s.
Are you implying that making member function virtual does 'chaining'? It's not the case, at least with C++ - you'll have to chain manually inserting base::init in derived::init. Virtual makes no difference here.
If you plan to create Foo only in static Foo::create (as you've mentioned before in this thread), then your init() doesn't have to be virtual at all. Inside Foo::create you have pointer to well-known Foo type, and there's no need to make init() virtual.
Tomasz Sowinski -- http://www.shooltz.com.pl
|
|
|
|
|
again, I understand the implementation techniques for virtual functions. However, NOT making the init() function virtual means you will not be able to do have this behaviour - rememeber that Foo will have to derive from some base class.
i.e.
class Base {
virtual void init() {
//do something
}
static Base* create() {
Base* result = new Base();
result->init();
return result;
}
};
class Foo : public Base
{
virtual void init() {
Base::init();
//do some more stuff
}
static Foo* create() {
Foo* result = new Foo();
result->init();
return result;
}
};
so calling
Base* b = Base::create()
means Base::init() gets called
while
Foo* f = Foo::create()
results in Base::init() and Foo::init() getting called. If init() was not virtual this would not work, correct ?
|
|
|
|
|
> If init() was not virtual this would not work, correct ?
Not correct. It would work without any problems as non-virtual. Note that the local variable 'result' in static Foo::create is of type Foo, not Base. The compiler will insert the direct call to Foo::init if init would be nonvirtual. If init() would be virtual, the generated code would use the vtable to jump indirectly to Foo::init. You'll get identical results.
Tomasz Sowinski -- http://www.shooltz.com.pl
|
|
|
|
|
OK now I see what you're saying, which makes sense I guess, and I suppose there is a small performance increase. Learn some thing new every day 
Thanks
|
|
|
|
|
Nice design! Do you plan to use Smart pointers too?
|
|
|
|
|
Yes, although this would be optional. I wanted the refcount implicit in the design so the pointers can be used without smart pointers if neccessary.
|
|
|
|
|
You may be interested to look at a similar scheme that is used by the open source package Visualization Toolkit. They use a scheme like this and have put a lot of thought into making it robust and fast.
They point out that you can do a lot of good optimizing if you can be sure that all objects are allocated on the heap (as opposed to global variable memory or on the stack), so they use static member functions New() and Delete() similar to your create() and destroy().
|
|
|
|
|
|
I need to read from the file a list of persons(person it is a struct that I defined)in unknown size , but I success to read only the first person.
then my loop being infinite.Why ??? What can I do ??? 
_______MY CODE___________________________________________
void CRegWinDlg::read_persons(CFile* persons)
{
person* q = new person;
if file.Read(q, sizeof(person)))
{
q->next = q->back = NULL;
p_head = p_tail = q;
}
else
{
MessageBox("Have not register of users ! ");
delete q;
return;
}
//---------------------------------- Until here it is working excellent !!!
file.Seek(sizeof(person), CFile::current);
while(file.GetPosition() != CFile::end )
{
p_person q = new person;
if(file.Read(q, sizeof(person)))
{
q->next = NULL;
q->back = p_tail;
p_tail->next = q;
p_tail = q;
}
else
delete q;
file.Seek(sizeof(person), CFile::current);
}
}
|
|
|
|
|
|
Geez, it was only like 40 minutes. Anyway, why are you calling Seek()? The file pointer automatically gets advanced when you read from the file.
|
|
|
|
|
I dont think you need to call Seek since Read advances the position. Also CFile::end, cannot be used to determine the end of the file... it is used for seeking from the end of the file.
You could try something like this;
...<br />
DWORD dwRead = 1;<br />
<br />
while ( dwRead > 0 ) {<br />
<br />
p_person q = new person; <br />
<br />
if ( 0 != ( dwRead = file.Read ( q, sizeof ( person ) ) ) ) {<br />
<br />
q->next = NULL;<br />
q->back = p_tail;<br />
p_tail->next = q;<br />
p_tail = q;<br />
<br />
}<br />
else {<br />
<br />
delete q;<br />
<br />
}<br />
<br />
}<br />
...
-Ben
---------
On the topic of code with no error handling -- It's not poor coding, it's "optimistic" 
|
|
|
|
|
Hello All,
I have my App as a SDI, With the CFormView as the base class of the view class. the problem is this,
when maximize the Main App window (to fill the screen) the Form doesn't get resized to fill the App main window, but it stays at its original size and location.
I was wondering if there is a way to get the view form (dialog) gets resized to fill the App main window when I maximize the App window, and to Get it to be resized to fill the App window if I resized the App.
Basically I want the View Form to occupy the App Main window at all times.
Thanks in advance.
Fady.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
