|
I am facing a problem in copying file in C:\windows\fonts folder in vista computer. my application is properly working on other machine but in vista i dont receive any error message but my file is not copying.can anyone give me solution y it is so
Yes U Can ...If U Can ,Dream it , U can do it ...ICAN
|
|
|
|
|
Shilpi Boosar wrote: copying file in C:\windows\fonts
How are you copying the file to the destination?
Shilpi Boosar wrote: my application is properly working on other machine but in vista i dont receive any error message but my file is not copying
Did you try and check by debugging what is happening behind your code? If not, please try it out.
Somethings seem HARD to do, until we know how to do them.
_AnShUmAn_
|
|
|
|
|
yes i debug it properly and i dont find any exception in opening and writing a file. and it will properly working on Common folder in vista like C:\
but not in C:\windows\fonts.
i import ttf file using resource and just copy and paste that file to fonts folder.
Yes U Can ...If U Can ,Dream it , U can do it ...ICAN
|
|
|
|
|
Try to login in Pure Admin user and then see. I hope it will work definitely.
Try it.
|
|
|
|
|
I have full rights but it is not working
Yes U Can ...If U Can ,Dream it , U can do it ...ICAN
|
|
|
|
|
|
Hi,
I have the following function
int DataPeakCompareFunc(const void *el1, const void *el2)
{
const DataPeak *peak1 = reinterpret_cast<const datapeak="" *="">(el1);
const DataPeak *peak2 = reinterpret_cast<const datapeak="" *="">(el2);
if (peak1->position < peak2->position)
{
return -1;
}
else if (peak2->position < peak1->position)
{
return 1;
}
return 0;
}
I am calling qsort function with the below parameters
qsort((void *)pScan, num_readings, sizeof(DataPeak), DataPeakCompareFunc);
Then i am getting the above error.
What to do?
Thanks in advance
|
|
|
|
|
subramanyeswari wrote: qsort((void *)pScan, num_readings, sizeof(DataPeak), DataPeakCompareFunc);
qsort((void *)pScan, num_readings, sizeof(DataPeak), <code>&</code>DataPeakCompareFunc);
Remember that this function should not be member function. Either it should be static or a global function.
Lookup qsort . Here is the callback function signature.
int (__cdecl *compare )(const void *elem1, const void *elem2 ) BTW why are you posting the whole error as caption for your post. Looks odd.
|
|
|
|
|
|
I swear I already answered this. I'll repeat:
Don't use qsort : it's crap, old, not type safe, etc....
Use STL instead. Here's an example:
#include "stdafx.h"
#include <algorithm>
class CData
{
public:
CData(int val) : m_val(val) {}
friend bool operator<(const CData &l, const CData &r)
{
return l.m_val < r.m_val;
}
private:
int m_val;
};
int main(int arvc, char* argv[])
{
CData SortMe[] = {10, 9, 8, 7, 6, 5, 4, 3, 2, 1};
CData *pOnePastEnd = SortMe + sizeof(SortMe)/sizeof(SortMe[0]);
std::sort(SortMe, pOnePastEnd);
return 0;
}
Steve
|
|
|
|
|
Stephen Hewitt wrote: Don't use qsort: not type safe, etc....
What do you mean by type safe? We are ones who's using it and we know what types we are passing to it. So how can you say it's not type safe.
Stephen Hewitt wrote: old,
Old is gold.
Stephen Hewitt wrote: it's crap
No it's not.
|
|
|
|
|
STL is obviously simpler, easier to understand and less messier than qsort can ever be. STL code would execute faster than the routines that we may generally write. Did you notice the STL code to sort a given array? That is 1 line! Brilliant use of operator overloading. If you are writing c++ code, I don't find a good reason to use qsort, instead of STL.
Nobody can give you wiser advice than yourself. - Cicero
|
|
|
|
|
brahmma wrote: If you are writing c++ code, I don't find a good reason to use qsort, instead of STL.
That doesn't mean qsort is crap and not type safe. If you are using it, then you have reasons. It's just a function call, I've used it, works well.
My company does not use STL. So qsort works well.
|
|
|
|
|
Nibu babu thomas wrote: That doesn't mean qsort is crap
Why do you tell that to *me*
Nibu babu thomas wrote: It's just a function call, I've used it, works well.
It works; I never said no. I was trying to compare qsort with an STL based solution. I felt when compared, STL is much better. My point is that if STL could be used instead of qsort, it must be, IMO!!
PS: I'm not voting you one.
Nobody can give you wiser advice than yourself. - Cicero
|
|
|
|
|
brahmma wrote: Why do you tell that to *me*
I've quoted the statement to which I am replying.
|
|
|
|
|
Nibu babu thomas wrote: That doesn't mean qsort is crap and not type safe. If you are using it, then you have reasons. It's just a function call, I've used it, works well.
There is no sane reason to use qsort in preference to std::sort in C++ code; it's (std::sort) better in every respect from type safety through to sorting speed and flexibility.
Nibu babu thomas wrote: My company does not use STL. So qsort works well.
Your company is making an error of judgment in this respect. If I was in charge the person responsible for this would have a lot of explaining to do.
Remember the mantra:
qsort is crap!
Steve
|
|
|
|
|
Nibu babu thomas wrote: Old is gold.
You must use Windows 3.11 :->
Nobody can give you wiser advice than yourself. - Cicero
|
|
|
|
|
Nibu babu thomas wrote: No it's not.
It is; 100% crap.
Steve
|
|
|
|
|
Nibu babu thomas wrote: What do you mean by type safe? We are ones who's using it and we know what types we are passing to it. So how can you say it's not type safe.
Look at the sorting callback; it uses reinterpret_cast s to recover type information which was discarded in the call to qsort (with the conversion to void* )! If that doesn't scream out for a better solution then I don't know what does. If the elements sorted were changed to a different type but the callback wasn't adjusted it will still compile and run but the reinterpret_cast s in the callback will result in strange runtime errors: this is one way in which the fact that qsort is not type safe can cause maintenance problems.
Steve
|
|
|
|
|
Apart from that, every time you use qsort, god kills a kitten.
Nobody can give you wiser advice than yourself. - Cicero
|
|
|
|
|
Stephen Hewitt wrote: Don't use qsort: it's crap, old, not type safe, etc....
Don't forget slow[^] (compared to std::sort)
|
|
|
|
|
Hi,
after having some problems with a self-drawn dialog to derive the CPrintDialog I have successfully sent the document to the printer. The problem is that I can only print 1 page, although the pInfo->GetMaxPage () returns the correct value it should print (from 1 to 9 depending on some things).
What should I check? the pInfo structure is correct (I have check it in debugger and with AfxMessageBox ()) but it doesn't print right yet.
Greetings.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
|
|
|
|
|
Hi,
2 minutes after posting the message I have solved it. I didn't set nFromPage and nToPage in pInfo->m_pPD->m_pd. (device) so...
thanks anyways
Greetings.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
|
|
|
|
|
I have few doubts about meomory allocations in program.
1. Which variables are allocated in stack and which are in heap.
2. How can the scope of the global and static variables is through out the application.
3. Why the varibles in stack cannot have program scope while the variables in the heap can have?
Can you please give me a link or two where i can get the information on memory allocation.
Thank you.
KIRAN PINJARLA
|
|
|
|
|
At first you should probably begin with reading about the stack[^] and the heap[^].
Regarding your questions:
1. Unless you allocate memory from the heap with calls like new , malloc(...) or similar and assign the returned value to a pointer variable, your data will be allocated on the stack.
In code the difference would look like this:
int foo()
{
int nValueOnStack;
int pnValueOnHeap = new int;
....
delete pnValueOnHeap;
}
2. I don't understand your question. It doesn't validate to a full sentence.
3. I'm not really sure what you mean. But I think you will get an answer when you read how the stack works in the link above.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote "High speed never compensates for wrong direction!" - unknown
|
|
|
|