|
You're welcome.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
I can not refresh the forms of my application when I execute the .exe file. Whether I click over my application then the screen seens to be frozen...same result if I do soemthing with another application like web browser...I've tried with refresh() and bringtofront() methods but it doesn't work.
I would really apreciate if someone could tell me how to keep the forms updated when it is running...
c u soon...
David
|
|
|
|
|
David21u2 wrote: I would really apreciate if someone could tell me how to keep the forms updated when it is running...
How did you initially populate them?
"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
|
|
|
|
|
Hi,
Thanks a lot for your help...
My issue is the following...when I'm running the .exe file... any further action I do with the mouse, lets say open another application or even click over my application cause that the screen gets frozen...i've added refresh() and Bringtofront() methods but they only work whether I run the application from the Builder IDE...
tks in advance for your help...
dg
|
|
|
|
|
David21u2 wrote: ...cause that the screen gets frozen...
Instead of what? Is your application doing something at that point?
"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
|
|
|
|
|
Yeah,
The application is a cellular networks simulator; some simulations are really heavy computationally speaking that the system I think is unable to refresh the graphical interface...but the curious thing is that only the app's screen gets frozen because the simulation itself keeps working properly; I've verified it because once the overall simulation process finishes then the application screen returns.
I've viewed some articles refering to threads but I have no idea how to use them...maybe there is another way !!
c u,
dg
|
|
|
|
|
David21u2 wrote: ...some simulations are really heavy computationally speaking that the system I think is unable to refresh the graphical interface...I've verified it because once the overall simulation process finishes then the application screen returns.
Put these computations into a worker thread.
"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
|
|
|
|
|
well,
could you give me please additional insight how to do that...i've never use such threads so a tutorial or maybe a sample file could be useful...
: )
tks
dg
|
|
|
|
|
See here.
"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
|
|
|
|
|
tks a lot for your help...I'm gonna go over that inmediately...
c u around..
dg
|
|
|
|
|
maybe your frequent refresh leads to the frosen, try to create a thread to refresh
|
|
|
|
|
hi,
do ou have a sample code showing how to do that...
I've never used threads and I found it a bit complicated...
well, tks a lot for your help...
c u around,
dg
|
|
|
|
|
Multithreading Tutorial[^]
you can download the code here，although it isn't in c++ builder. It is written by api, hope it helpful.
anyway, i think the code in msdn is also valuable.
|
|
|
|
|
|
Hi,
I dont know whether there are some issues implementing threads by means of MFC in Borland C++ Builder.
I have found some problems with CWinThread class in Builder... have you some additional comments regarding it ?
tks a lot for your help...
|
|
|
|
|
MFC is a part of Visual C++, not for C++ builder, maybe the idea is useful.
If you do not want to use api or read codes in visual c++, please use TThread in c++ builder. there is an example contained in c++ builder
D:\Program Files\Borland\CBuilder6\Examples\Apps\Threads
you can file->new->others->thread object to create a new thread, See more in help file of TThread
|
|
|
|
|
Hello,
I am no stranger to the idea that when you call 'new obj' it allocates dynamic memory of the heap, yada yada yada. Mainly call the corresponding 'delete obj' as is dictated by the language.
my question is with the practice of using it as you call a function:
...foo (new bar ())...
I've seen this done a lot, i was wondering why. it is a nice syntax, looks good, but seems dangerous. no handle to the obj to delete it, relying on the underlying func to take responsibility, dangerous most def. i feel like i am missing something about it. Ideas?
|
|
|
|
|
I personally have never written this kind of code, but have worked with such code. For example, such a function expects a pointer to some class object (to be on the heap). You can call the function from within a thread, and forget it. The function then guarantees clean up of the passed object.
The function code looks typically like this:
void foo(CBar *bar)
{
if(bar == NULL)
{
return;
}
delete bar;
}
So, you can call the function safely like: foo(new bar());
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
i'd be very nervous if i ran across that in anything i was working on. unless the function is called DoSomethingThenDeleteTheInputObject, yes, dangerous indeed.
|
|
|
|
|
Definitely. I second it.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
That was pretty common in 1990s when people were trying to emulate Smalltalk with C++. For instance, you'll see a lot of such code in the GoF book.
Today it is not considered a good C++ coding style because of the problems you mention
|
|
|
|
|
Nemanja Trifunovic wrote: For instance, you'll see a lot of such code in the GoF book.
Actually I don't remember it in the book (anyway my memory is far from being perfect...  ).
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Others pointed no good reasons but I say one situation of no bad.
1) such classes is not wrapper of system object; like HANDLE.
2) such classes need to be active while the program's alive.
An example is neural network programing. In such case, there is usually no need to delete at the end of program.
|
|
|
|
|
I occasionally use that construct in collection classes.
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
I'm having an issue with the zoom method of NTGraph. Basically the code is as follows:
void CPlot1To1NBBBRSvsIL::OnZoomIn()
{
m_Graph.AutoZoomIn(0.0);
}
void CPlot1To1NBBBRSvsIL::OnZoomOut()
{
m_Graph.AutoZoomOut (0.0);
}
Where when I step into the function during debug it goes into NTGraph.cpp at
void CNTGraph::AutoZoomIn(double zoomPercent)
{
static BYTE parms[] =
VTS_R8;
InvokeHelper(0x53, DISPATCH_METHOD, VT_EMPTY, NULL, parms,
zoomPercent);
}
void CNTGraph::AutoZoomOut(double zoomPercent)
{
static BYTE parms[] =
VTS_R8;
InvokeHelper(0x54, DISPATCH_METHOD, VT_EMPTY, NULL, parms,
zoomPercent);
}
The problem is that I do not know what the default zoomPercent is, when I watch the variable it is set to 0.0, but if I change it to
m_Graph.AutoZoomOut (50.0);
It ceases to zoom at all, where it previously would zoom an unknown amount. I've also tried using
m_Graph.SetAutoZoomPercentage(50);
For both ways I tried using various numbers between 200 and .01 as I was not sure if it was truly in percentage format, but this did not make any difference.
Please let me know if you can tell me how the zoom function works and by what percent it goes by (in x and y), the goal being to create some code to reformat the y-axis upon zooming, which currently seems to be faulty if zoomPercent is left at 0.0.
It might be worth noting that upon zooming out, the y axis does indeed adjust accordingly, it's only zoomin thats a problem...
Thank you for your time,
KevinVS
modified on Friday, June 26, 2009 10:42 AM
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
