|
can u explain it some what clearly
manu
|
|
|
|
|
When you run a process the exe file on the hard drive becomes locked. Usually to unlock a file you kill the process using it(which would be itself), but the process i would have to kill is the one that I need to modify it.
|
|
|
|
|
Maybe start another process to do the modification and end the process to be modified.
When the modification is complete, the modifier process can restart the modified process.
|
|
|
|
|
Good People,
Does "IMPLEMENT_DYNCREATE" (and DECLARE_DYNCREATE) mean that I don't have to use the "new" declaration when creating an object. In other words, do those two macro amount to using the "new" declaration (i.e. using free memory)? Is that what MFC means when it says the classes using those macros are created dynamically?
Thank you,
BP
|
|
|
|
|
BlitzPackage wrote: Does "IMPLEMENT_DYNCREATE" (and DECLARE_DYNCREATE) mean that I don't have to use the "new" declaration when creating an object.
No.
BlitzPackage wrote: Is that what MFC means when it says the classes using those macros are created dynamically?
It means that MFC can create an instance of your class dynamically.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Forgive me for asking, but what does "create an instance of your class dynamically" mean if it does not mean that it allocates it in the same way that "new" allocates it?
|
|
|
|
|
Take a look at the source code for the macro.
It adds members to your class so the MFC framework is able to create an object of your class.
This is important, at least, in MFC Doc/View and CObject serialization.
Without this, MFC would know nothing about your classes so it couldn't create an object of your
class 
BTW, MFC will still use new to create the object.
|
|
|
|
|
Workspace is a class created as a child of DockSpace (sub-class of CToolBar).
//DockSpace*p_DockSpace;
UINT u=WS_CHILD|WS_VISIBLE|CBRS_RIGHT;
p_DockSpace->Create(this,RUNTIME_CLASS(Workspace),
(CCreateContext*)(pCS->lpCreateParams), "Workspace",u,AFX_IDW_CONTROLBAR_FIRST+33);
//--------------------------
Question:
how to get the pointer to Workspace in DockSpace?
such as:
void DockSpace::SomePlace()
{
Workspace*pWs=GetItByXYZ();
}
is there a function GetItByXYZ() or something to get the pointer to Workspace created by RUNTIME_CLASS?
|
|
|
|
|
what the hell is the problem with respecting the forum's posting guidelines (5.)[^] ?
you've been using Codeproject for more than 4.5 years now, and still you can't post your code samples within <pre> tags ?
come on, edit your post please 
|
|
|
|
|
toxcct wrote:
ou've been using Codeproject for more than 4.5 years now, and still you can't post your code samples within
tags ?
calm down my friend!
<div class='ForumSig'>"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers, Alok Gupta VC Forum Q&A :- I/ IV Support CRY- Child Relief and you </div>
|
|
|
|
|
seriously... why not posting "plain english code" when he's there ?
Chris submited forums guidelines ; we MUST respect them to keep a nice place...
|
|
|
|
|
my post is quite clear, u just go away and do not make so many rubish here.
|
|
|
|
|
includeh10 wrote: how to get the pointer to Workspace in DockSpace?
I would make a Function "Init" in the Dockspace-class, called after Create, that would take a Workspace-pointer and stores it for further use.
But maybe the Parent-Window that is handed down via the Create-calls from CToolBar down to CWnd suffices?
You can get it in PreCreateWindow as the hwndparent-Parameter of the CREATESTRUCT, I think.
"We trained hard, but it seemed that every time we were beginning to form up into teams we would be reorganised. I was to learn later in life that we tend to meet any new situation by reorganising: and a wonderful method it can be for creating the illusion of progress, while producing confusion, inefficiency and demoralisation."
-- Caius Petronius, Roman Consul, 66 A.D.
|
|
|
|
|
Hi,
I would like to know if I can perform various types of digital image processing techiniques using Image processing functions of Intel's IPP libraries. I would like to perform operations like FIR filtering (right from creating using frequency response matrix [meshgrid] and then window it [like disk]) and then do some morphological operations etc. These are pretty much stright forward in Matlab, but I would like to implement the whole program in c++.
Anyone have any idea/suggestion??
thanks,
-Pavan.
|
|
|
|
|
Yes, you can. Intel's Integrated Performance Primitives has a library for signal and image processing. It is implemented using SIMD and supports multi-core processors as well. The library is vast, and contains many types of filters in spatial and freq domain. It also has morphological functions too. In fact, matlab is using IPPI to accelerate some image processing operations.
You can check for the presence of IPP in your matlab by typing the ippl command in the console;
[T b ] = ippl
Matlab 2006a usese version 2.0 of IPP, the latest version is version 5.1 (and 5.2 beta if you want to try out.) http://www.intel.com/software/products/ipp/beta.htm
By the way, programming with IPP requires you to handle all sorts of memory management, alignment etc, unlike the simplicity of Matlab.
Good luck,
|
|
|
|
|
Thanks in advance, fellow coders.
I am creating a dialog based app in MSVC++ 6.0.
[No I AM NOT switching to .NET, or should I say .NOT working, LoL).
Anyway, my dilema is this :
I have 1 main dialog, an AboutBox, and 7 child dialogs.
My functions / code for my child dialog buttons wil not work. The exact same code will work when tested in the main dialog or the AboutBox. The AboutBox is a default modal dialog generated by MFC using DoModal. I have now idea how DoModal works [code please?], but I am going for modeless, preferably anyway.
This is a snippet of code [from my main dialog's .cpp file], used to dispaly one of the modeless dialog boxes :
void CInvenStoryDlg::OnButtonNewitem()
{
CInvenStoryDlg *dlg = new CInvenStoryDlg ();
dlg->Create(IDD_DIALOG_NEWITEM, this);
dlg->ShowWindow(SW_SHOW);
}
As you all can tell, I have one heck of a memory leak going here. I know I should use DetroyWindow() for modeless dialogs, as oppossed to EndDialog() for Modal ones, but where in the world do I actually PUT that code?
I assume in the code for the parent dialog, but I want to be sure.
This is a snippet of code [from one of my child dialog's .cpp file]. The code is supposed to be activated when a certain button is clicked. It should read some text from an EditBox into a CSTring, and then fwrite it to a .TXT file in binary mode.
[There is a reason that it is in binary mode instead of ASCII, but that is not relevant here.]
Anyway, here is the function :
void CDialogNewItem::OnButtonWriteNew()
{
#include <stdio.h>
FILE *stream;
int b;
GetDlgItemText(IDC_EDIT_ITEMNAME, m_newitemname);
b = m_newitemname.GetLength();
MessageBox(m_newitemname);
if( (stream = fopen("filename.txt","wb")) != NULL )
{
fwrite(m_newitemname,1,b,stream);
fclose(stream);
}
else
MessageBox("File could not be opened\n");
}
Yes, yes, I know header includes go up top; this was just for experimental purposes. All will be relocated properly upon final completion ... 
As I stated before, the [guts] of this function work fine when used in either the main dialog or on the AboutBox, but not in a child dialog. Is it my dialog box settings?
my dialog Create methods? What??!? I've tried everything.
Anyway, I'd like to see code for functional child dialogs, both Modal and Modeless versions, created and destroyed properly. Please speak in English, people, like a normal human, instead of all of that
micro$oft double-talk ala MSDN flavor :
Hwnd, *pArent, (LPCSTR): Be all you can be in the ARMY, COleInsertDialog::DoModal virtual int DoModal( ); int DoModal( DWORD dwFlags );
Whatever the ##@$% all that garble means. Give me actual code please, and no code for
CAboutDlg dlgAbout;
dlgAbout.DoModal();
I have plenty, but I won't be able to understand it until someone shows me how it works for a custom Dilaog, say, like for mine named IDD_DIALOG_NEWITEM.
Anywho, thankees for all the help, and please, dumb it down a bit, use #includes where needed, and please, please, use comments. A download for a full VC6 project covering this material wouldn't hurt either. Appreciate it peoples ... Happy Codin' ...
-digitalmythology -dm
|
|
|
|
|
digitalmythology wrote: or should I say .NOT working
Actually, .NET would deal with your memory leaks, eventually.
digitalmythology wrote: CInvenStoryDlg *dlg = new CInvenStoryDlg (/*... construction args ... */);dlg->Create(IDD_DIALOG_NEWITEM, this);dlg->ShowWindow(SW_SHOW);
A modeless dialog needs to be a member variable. Otherwise, you've thrown a pointer to the wind, and have no way to do anything with it from there on in.
digitalmythology wrote: (stream = fopen("filename.txt","wb")
You should use C++ to handle files, C is nasty.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
Reposting my own code is not much of a help. I need code that shows how to do it correctly.
'A modeless dialog needs to be a member variable. Otherwise, you've thrown a pointer to the wind, and have no way to do anything with it from there on in."
I've heard of this solution before, but how do I actually DO it? Just saying it works for most people, but , as I" am a tactical person at times, I need to see actual code.
What variable type does the dialog box need to be? CString, int, BOOL, or what? Apologies if I sound crabby, but there are millions pf sites out there on the 'ignorant net', and most issues I can resolve with research, trial, and error. However, there occassionally comes an issue to which everybody has an answer, but nobody wants to show how its actually done. What's the big M$DN secret on these subjects?
Thanks, again. I really appreciate it.
-digitalmythology -dm
|
|
|
|
|
Try using a member variable of type CInvenStoryDlg. In your header
CInvenStoryDlg *m_pdlg ;
In your constructor(s) initialise it to NULL
m_pdlg = NULL;
Change creation code to use the member variable:
void CInvenStoryDlg::OnButtonNewitem()
{
m_pdlg = new CInvenStoryDlg ();
m_pdlg ->Create(IDD_DIALOG_NEWITEM, this);
m_pdlg->ShowWindow(SW_SHOW);
}
In you destructor check if is not NULL otherwise DestroyWindow.
|
|
|
|
|
digitalmythology wrote: most issues I can resolve with research, trial, and error.
I find that difficult to believe, in light of this comment:
digitalmythology wrote: What variable type does the dialog box need to be?
digitalmythology wrote: However, there occassionally comes an issue to which everybody has an answer, but nobody wants to show how its actually done
Sometimes, things are so simple, we assume that an explanation is enough.
If you created a CMyDlg * locally, what would your member variable be, if not a CMyDlg * ? What else COULD it be ?
A member variable, of the right type. Set to NULL in your constructor. Set to a value when you show it. Reset to NULL and deleted both in your destructor and the code which hides it otherwise.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
digitalmythology wrote: void CInvenStoryDlg::OnButtonNewitem()
{
// TODO: Add your control notification handler code here
CInvenStoryDlg *dlg = new c (/*... construction args ... */);
Is this right, in that you are creating another instance of CInvenStoryDlg?
digitalmythology wrote: I know I should use DetroyWindow() for modeless dialogs, as oppossed to EndDialog() for Modal ones, but where in the world do I actually PUT that code?
At the point in which you are done with the modeless dialog.
digitalmythology wrote: ...but not in a child dialog.
Which means what exactly?
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Not creating another instance, but rather creating a child dialog [of which I am clueless]. I prefer dto do a modeless version, but want to see Modal code as well.
And thanks for the tip on "at the point of when you are through with it", but what I meant was where does the code GO? Probably CSomeClassName::OnDestroy(); but could you "dumb it down" for me? does code to destroy a child dialog go in the .cpp file for that dialog, or the .cpp file for the main dialog [parent that calls it]?
"Not in a child dialog" means :
that any code I write, [which is correct], will execute properly when used in the main dialog and by clicking the appropriate button on the main dialog. The exact same code will not work for a button on any of the child dialogs, except for the default AboutBox that MSVC6 included in the project. My guess is that I am not construction method[s] are wrong for the child dialogs that I made.
Thanks for the help .... message me on Y! at digitalmythogy
-digitalmythology -dm
|
|
|
|
|
digitalmythology wrote: Not creating another instance...
But you are in a CInvenStoryDlg method when you create another instance of CInvenStoryDlg. Is that your intention?
digitalmythology wrote: ...what I meant was where does the code GO?
You call DestroyWindow() whenever you are done with the modeless dialog. It's up to you to determine where that is.
digitalmythology wrote: My guess is that I am not construction method[s] are wrong for the child dialogs that I made.
I suspect this is true. Notice how the About box has its own CDialog-derived class.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Is there a simple way to change the BG color (and maybe text color also) of an editbox? I only need two colors to be toggled by clicking a button. I wanted to toggle the color of the button, but found out that it can only be done using images as buttons, which seemed too complicated for me.
|
|
|
|
|
Not really. An edit box is really nasty, as it paints itself outside the normal WM_PAINT method, so any owner drawing tends to get erased as you type. It can be done, but not without flicker, and not as trivially as, say, a button. To change the color of a button, you can derive a class from the button class, and draw the background yourself. No bitmap needed.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
