|
Ok...I have tried whatever you told,but I have a problem,I have added the progressbar in the intermediate dialog,the function defination and the function body for each value is in "Convertion form" for convertion,so if I have to include a m_prg.StepIt() or prg.StepIt() after each function,the m_prg variable must be recognised by convertion form,but it is added for the progressbar which is in the intermediate dialog.So now how to use the variable defined in one form by the other?Because it I use m_prg.StepIt()statement after each function in conversion form,It says the variable m_prg is not declared.So how to do it?Please tell me.
|
|
|
|
|
You can either make the m_prg variable as public as access it from the other dialog or you can create a public function in the intermediate dialog which calls m_prg.StepIt() and call that public function from the main dialog.
«_Superman_»
I love work. It gives me something to do between weekends.
|
|
|
|
|
I tried as you told..
I have put the
m_prg.SetRange(0,100);
m_prg.SetStep(10);
in the initDialog() of the intermediate dialog.I have create a function connect() here as
void CProcessDlg::connect()
{
m_prg.StepIt();
}
and I have defined the m_prg as above..and then after each function in the convertion form,I have put the bellow statement
CProcessDlg::connect();
It should work right?
It is executing,no error or anything,but the progressbar should show progress na,but nothing is happening..where did I go wrong?
|
|
|
|
|
kokilag wrote: ...the intermediate dialog...
This was not mentioned in your initial post. How many dialogs are there, one or two?
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
K..I will try that method..oops..sorry the dialog which I mentioned in my earlier post..I called it as an intermediate dialog.
|
|
|
|
|
kokilag wrote: ...the dialog which I mentioned in my earlier post..I called it as an intermediate dialog.
Is it used just for displaying the progress bar?
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
Yes..I have created a dialog box just like a message box,which will be displayed with a message saying.."Processing...pls wait" when the convertion takes place.Now I am trying to put a progress bar there so that with the message we can also know how much is completed too while it is processing.
|
|
|
|
|
So just create a modeless dialog with text and a progress bar right before the processing starts (Create() ), update it in the processing loop (SetPos() ), and destroy it afterwards. It's really quite simple.
Here are a few examples:
Tutorial - Modeless Dialogs with MFC[^]
Modeless Dialog Boxes in MFC - MFC Tutorial Part 6[^]
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
Thank u for the material.But one was in VC++.Net.Can I get some solution purely in VC++ MFC because I went through the articles.Sorry,I never found much details regarding the solution.Can u pls suggest me..
|
|
|
|
|
kokilag wrote: Can u pls suggest me..
I already have. Create a modeless dialog, having text and progress bar controls, right before the processing starts (Create() ), update it in the processing loop (SetPos() ), and destroy it afterwards. It's really quite simple.
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
Hello,
I have a DLL that expose an API that stream video (JPEG) to a window that I create and pass its handler as an argument to that API. The video stream is then display on screen. I need to break this stream into frames and do some task on them. How can I do it?
Thanks,
Eyal
|
|
|
|
|
I know that it works on the heap...
char * sz1 = "Text";
char * sz = new char[strlen(sz1)]; ...and I know that this will give me an error saying that a constant is expected:
char * sz1 = "Text";
char sz[strlen(sz1)];
...So is there some other way to create an array on the stack whose size is not hard-coded ? I've seen things like:
char char * szBuff[iSomeLargeNumber];
char * sz1 = "Text";
strcpy(szBuff, sz1); But no matter how large iSomeLargeNumber is, there's still a hard-coded limit... and declaring a large array on the stack uses the full amount of memory even if the full array isn't populated...(right?)
Is the heap the only answer?
As always, thanks for putting up with the nooB..
MZR
|
|
|
|
|
|
You could use
char * sz1 = "Text";
char* sz = (char*)<a href="http://msdn.microsoft.com/en-us/library/wb1s57t5.aspx">_alloca</a>(strlen(sz1));
but make sure you don't exhaust available stack space (starts at 1MB and decreases for standard Windows threads).
These days, Microsoft want you to use _malloca[^] instead - it's more safe apparently.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
In addition, you've don't have to free pointer allocated using _alloca or _malloca because stack will cleared when the function is returned.
-Sarath.
"Great hopes make everything great possible" - Benjamin Franklin
|
|
|
|
|
...though that 1mb limit is rather unfortunate, for my current project.
I'll have to use the heap after all, but it's a good thing to know for the future.
MZR
|
|
|
|
|
You can change the default stack size from the project properties.
Project Properties -> Configuration Properties -> Linker -> System -> Stack Reserve Size / Stack Commit Size.
Look at the documentation for the /STACK[^] linker option.
«_Superman_»
I love work. It gives me something to do between weekends.
|
|
|
|
|
You're welcome, but please don't write my name like that..
|
|
|
|
|
I think this is not going in the stack but rather in the string table. My advice is to avoid this approach.
The narrow specialist in the broad sense of the word is a complete idiot in the narrow sense of the word.
Advertise here – minimum three posts per day are guaranteed.
|
|
|
|
|
Are you really sure you want to allocate large chunks of data on the stack?
Off the top of my head I can't think of any really good reason for doing this, and it seems to be more trouble than it's worth compared to heap allocation.
There are three kinds of people in the world - those who can count and those who can't...
|
|
|
|
|
I'm writing an ISAPI extension to handle form data including one or more file uploads.
Most of what I've read on ISAPI extensions has indicated that time and memory are of the essence, and, because of that, using the heap should be avoided, as much as is reasonable, in favor of using the stack.
I understand a few parts of the stack/heap concept, but my knowledge (and understanding) is severly lacking in this area. As such, I didn't know whether or not trying to place the entire HTTP-REQUEST (including the uploaded files) on the stack was possible or reasonable until I asked.
That said, when I asked about dynamically sizing an array I was more thinking about "standard-length" strings...
I have been programming for several years, but, until the past couple years, almost exclusively in higher-level languages that didn't require me to keep track of memory. And, when I started with C++, I was using managed C++ with its garbage-collection crutch.
Now that I'm trying (or having) to ditch the __gc , I try to keep things on the stack as much as possible. Tracking down those ommitted delete s is a pain, especially for often-changed member variables where I tend to forget to delete the existing object/value before creating the new one.
Thank you for your patience in guiding the nooB!
MZR
|
|
|
|
|
Mike the Red wrote: I try to keep things on the stack as much as possible.
That's reasonable. The general maxim in C++ is to use the stack except when you need to use the heap.
Mike the Red wrote: Tracking down those ommitted deletes is a pain, especially for often-changed member variables where I tend to forget to delete the existing object/value before creating the new one.
Unless you have certain constraints within ISAPI (I'm not familiar with it) you should use Standard C++ (STL) and Boost to help you with such matters, i.e., avoid raw new and delete.
However, there is a learning curve and I don't know how long you've been doing C++ for.
For arrays you could use the STL vector. Then you don't need to worry about new and delete for dynamically sizing the array.
Kevin
|
|
|
|
|
I do not pretend to be an ISAPI expert, but you're trying to get into some kind of hand-crafted memory management. This can be more dangerous than you imagine. Try using some of those existing and well tested libraries like stl, mfc, etc.,
Agreed that utilising the stack as much as possible is a good thing, but I don't think that it is going to make *that much* of a difference on any normal application. If you try pushing the stack to its limits, there's also a danger of stack overflow.
I'll humbly suggest you to drop this idea of 'manual' memory management adventure. For all the pain that it could cause, it isn't worth. Frequent allocation and deallocation of the heap can fragment it and there are memory damage possibilities, memory leaks, etc., I won't ever choose something of this sort, unless I'm writing a memory manager or something like that myself.
Pick an existing library and it would use the heap in the best possible way for you.
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
Mike the Red wrote: using the heap should be avoided, as much as is reasonable
I think > than around 10kB of allocation probably crosses the boundary of reasonable and unreasonable avoidance of heap usage
Mike the Red wrote: Tracking down those ommitted deletes is a pain, especially for often-changed member variables where I tend to forget to delete the existing object/value before creating the new one
If you're using VC2008, then std::tr1::shared_ptr[^] is handy.
If not (or even if you are - see shared_array), then Boost.SmartPointers[^] is handy.
The best advice is to wrap resource allocation/deallocation in an object[^] (allocation in constructors, deallocation in the destructor), so you can tie the resource usage to the object's lifetime. That's how the STL containers (vector, list, map, set etc) work.
C++ (when written in a nice idiomatic way) relies on deterministic destruction to manage resources - when done right, it makes programming as easy as using garbage collection, IMO.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Hello All,
I am trying to Export data in Excel From MySql DataBase.But How to Create Fields and Data of Table in Row and Colume Format.
Thanks
If you can think then I Can.
|
|
|
|