|
Hi All
Can i save change excel *.xls to *.xlsx?
|
|
|
|
|
Please help me some one..
|
|
|
|
|
yes.. you can change the extension by using as Save As option
|
|
|
|
|
thanks for reply .I know that change the extension by using as Save As option.But how it is possible through code.
|
|
|
|
|
Hi,
I have a interface to interact with MS-Access database file. I m using CODBCRecordset for accessing DB.
CODBCRecordset class[^]
It was working fine untill I added new field in one of the table.
I added new field ("Lock1" - a integer field) in table (called "Quotation_DB").
This table have bunch of data (int,double,strings). I have a button in my interface which will set this "Lock1" field to 0/1 in separate function. when i click this button i get following error.
//==================
Expression too complex
Expression too complex
//==================
yes it is printing same message twice.
any kind of help will be good to me. Please let me know if i have to provide more information.
This is what i m doing in my function.
BOOL LockUnlockQuotation(BOOL flg_lock)
{
CODBCRecordset m_RS_RFQ(&DataBase);
BOOL flg_update = false;
if( !m_RS_RFQ.Open("SELECT * FROM \"Quotation_DB\"") )
{
TRACE("Failed to run query: \"%s\"\n","SELECT * FROM \"Quotation_DB\"");
return false;
}
else
{
if(!m_RS_RFQ.IsEOF())
{
m_RS_RFQ.MoveFirst();
}
CString Quot_revID_db="";
while(!m_RS_RFQ.IsEOF())
{
Quot_revID_db=m_RS_RFQ.GetString("QuotID");
if(Quot_revID.Compare("MyQoute2009")==0)
{
m_RS_RFQ.Edit();
m_RS_RFQ.Field("Lock")=1;
m_RS_RFQ.Update();
flg_update =true;
break;
}
m_RS_RFQ.MoveNext();
}
m_RS_RFQ.Close();
}
return flg_update;
}
modified on Wednesday, September 23, 2009 3:08 PM
|
|
|
|
|
is there any fix for this?
modified on Wednesday, September 23, 2009 2:59 PM
|
|
|
|
|
Hi,
I have a interface to interact with MS-Access database file. I m using CODBCRecordset for accessing DB.
CODBCRecordset class[^]
It was working fine untill I added new field in one of the table.
I added new field ("Lock1" - a integer field) in table (called "Quotation_DB").
This table have bunch of data (int,double,strings). I have a button in my interface which will set this "Lock1" field to 0/1 in separate function. when i click this button i get following error.
//==================
Expression too complex
Expression too complex
//==================
yes its print same message twice.
any kind of help will be good to me. Please let me know if i have to provide more information.
This is what i m doing in my function.
BOOL LockUnlockQuotation(BOOL flg_lock)
{
CODBCRecordset m_RS_RFQ(&DataBase);
BOOL flg_update = false;
if( !m_RS_RFQ.Open("SELECT * FROM \"Quotation_DB\"") )
{
TRACE("Failed to run query: \"%s\"\n","SELECT * FROM \"Quotation_DB\"");
return false;
}
else
{
if(!m_RS_RFQ.IsEOF())
{
m_RS_RFQ.MoveFirst();
}
CString Quot_revID_db="";
while(!m_RS_RFQ.IsEOF())
{
Quot_revID_db=m_RS_RFQ.GetString("QuotID");
if(Quot_revID.Compare("MyQoute2009")==0)
{
m_RS_RFQ.Edit();
m_RS_RFQ.Field("Lock")=1;
m_RS_RFQ.Update();
flg_update =true;
break;
}
m_RS_RFQ.MoveNext();
}
m_RS_RFQ.Close();
}
return flg_update;
}
|
|
|
|
|
is there any fix for this?
modified on Wednesday, September 23, 2009 2:59 PM
|
|
|
|
|
UNIT SimpleThread::ThreadFunc(LPARAM lp)
{
While(1)
{
printf("Test");
}
}
SimpleThread::Start()
{
DWORD dwThreadId, dwThrdParam = 1;
threadHandle = CreateThread(
NULL,
0,
SimpleThread::ThreadFunc,
dwThrdParam,
0,
&dwThreadId);
}
When call the thread it does't get called. Also somtimes it called but the while loop terminate within a while.Can any give me solution to this
|
|
|
|
|
VVVimal wrote: SimpleThread::Start()
What happens to the main thread after the creation of the thread?
|
|
|
|
|
AFAIK,
we cannot use a normal member function of a class as a thread.
there is a different procedure for this, let me remember.
but as a temporary solution, i can suggest you to use ThreadFunc as a global function and see.
good luck.
--------------------------------------------
Suggestion to the members:
Please prefix your main thread subject with [SOLVED] if it is solved.
thanks.
chandu.
|
|
|
|
|
UNIT SimpleThread::ThreadFunc(LPARAM lp)
{
While(1)
{
printf("Test");
}
}
SimpleThread::Start()
{
DWORD dwThreadId, dwThrdParam = 1;
threadHandle = CreateThread(
NULL,
0,
SimpleThread::ThreadFunc,
dwThrdParam,
0,
&dwThreadId);
}
When call the thread it does't get called. Also somtimes it called but the while loop terminate within a while.Can any give me solution to this
|
|
|
|
|
How can you even compile your code (there are a lot of errors)?
The following one works properly
#include <windows.h>
class SimpleThread
{
static DWORD WINAPI ThreadFunc(LPVOID p)
{
while(1)
{
printf("Test");
}
}
public:
void SimpleThread::Start()
{
DWORD dwThreadId, dwThrdParam = 1;
HANDLE threadHandle;
threadHandle = CreateThread(
NULL,
0,
ThreadFunc,
&dwThrdParam,
0,
&dwThreadId);
}
};
void main()
{
SimpleThread t;
t.Start();
while (1);
}
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]
|
|
|
|
|
Hello, everyone
I've wrote a code which will find the intersection of two given Linked lists sorted in increasing order.
Actually the code is running fine now, but I find a problem during compiling, but I dont know the reason,
so, hope someone know what's cause the problem. Thank you!
Problem is, if I put /* dummy.next = NULL; */ in front of /* struct node* tail = &dummy; */,
there will be errors, otherwise, problem running fine. Following is the function I wrote.
Thank you all.
// create a new list with the intersection of two given lists sorted in increasing order
struct node* SortedIntersect(struct node* head1, struct node* head2)
{
struct node dummy;
struct node* tail = &dummy;
dummy.next = NULL;
while(head1 != NULL && head2 != NULL)
{
if(head1->data == head2->data)
{
Push(&(tail->next), head1->data);
tail = tail->next;
head1 = head1->next;
head2 = head2->next;
}
else if(head1->data > head2->data)
{
head2 = head2->next;
}
else
{
head1 = head1->next;
}
}
return dummy.next;
}
modified on Wednesday, September 23, 2009 2:35 PM
|
|
|
|
|
is this C or C++?
In C, all the variable declaration should be wrttien in the begining of the function before any other code.
|
|
|
|
|
I am attempting to write some atomicInc functions that take 16 or 32 bit signed arguments, and call the appropriate _InterlockedIncrement intrinsic function when compiled in Visual Studio 2008. However, it appears the function _InterlockedIncrement takes a 64-bit integer on my system (Windows XP SP2 64-bit Pro), even though the documentation states that _InterlockedIncrement is the 32-bit version of the function call.
My question is, what intrinsic should I use to atomically increment a 32-bit value? The following is producing an error:
#include <intrin.h>
#pragma intrinsic (_InterlockedIncrement, _InterlockedIncrement16)
__int16 atomicInc(__int16 *val) {
return _InterlockedIncrement16(val);
}
__int32 atomicInc(__int32 *val) {
return _InterlockedIncrement (val);
}Any help is greatly appreciated. Thanks,
Sounds like somebody's got a case of the Mondays
-Jeff
modified on Tuesday, September 22, 2009 5:37 PM
|
|
|
|
|
A failing on MS part i think.
http://msdn.microsoft.com/en-us/library/29dh1w7z(VS.80).aspx[^]
__in32 == int, int != long (as data types are concerned).
They should have made __int32 == long.
You have 2 choices:
__int32 atomicInc(__int32 *val) {
return (__int32)_InterlockedIncrement((long*)val);
}
or
__int32 atomicInc(long *val) {
return (__int32)_InterlockedIncrement(val);
}
...cmk
The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.
- John Carmack
|
|
|
|
|
cmk wrote: __int32 atomicInc(__int32 *val) {
return (__int32)_InterlockedIncrement((long*)val);
}
Do __int32 and __int64 variables have the same alignment requirements in memory? I was under the impression that an __int64 had to have 8-byte alignment, whereas an __int32 had to have only 4-byte alignment. Therefore, wouldn't I have a 50% chance of getting a runtime error when attempting to dereference the __int64*? Will converting an "__int32*" to an "__int64*" always guarantee the bits from the original digit are in the least-significant position, or does this depend on hardware endianess? Thanks,
Sounds like somebody's got a case of the Mondays
-Jeff
|
|
|
|
|
Not sure I understand your question, how did __int64 enter the discussion ?
_InterlockedIncrement is for 32bit values only (long).
A long is 4 bytes on both 32bit and 64bit systems.
...cmk
The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.
- John Carmack
|
|
|
|
|
I didn't realize that type int is logically equivalent to type long... I thought a long was 64-bits (as you can guess, I always use the __intN types for integers so I know how many bits I have to work with)
So if I understand correctly, long and int are both 32-bit signed integer types, are built into ANSI C as keywords, but the compiler can't resolve this equivalence at compile-time? I'm confused... why can't the compiler figure out this equivalence without explicit type conversions? Thanks,
Sounds like somebody's got a case of the Mondays
-Jeff
modified on Tuesday, September 22, 2009 5:21 PM
|
|
|
|
|
A float is also 4 bytes. They are different types - period, it doesn't matter if they are both integer types.
http://msdn.microsoft.com/en-us/library/s3f49ktz(VS.80).aspx[^]
...cmk
The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.
- John Carmack
|
|
|
|
|
Jeff,
Skippums wrote: I am attempting to write some atomicInc functions that take 16 or 32 bit signed arguments, and call the appropriate _InterlockedIncrement intrinsic function when compiled in Visual Studio 2008.
This statement shows that you fundamentally do not understand atomicity. While it is probably true that the compiler will optimize the functions above directly into a call to _InterlockedX functions. Your atomic operations have just become subject to compiler optimizer probability.
You need to call the Interlocked functions directly. Do not call them through a proxy function.
Best Wishes,
-David Delaune
|
|
|
|
|
I don't understand why, if not actually placed inline, the new code runs the risk of not being thread safe. Can you explain this? As far as I can tell, the value will still be modified and returned by value atomically. Therefore, no matter what the optimizer does, I still always get the correct value returned as well as the correct value set. Seems logical to me, unless the compiler can optimize the intrinsic function to return by reference, which means that the intrinsic is incorrectly implemented. Please let me know how this could possibly not be thread safe.
Sounds like somebody's got a case of the Mondays
-Jeff
|
|
|
|
|
Jeff,
A context switch[^] can occur at the top of your atomicInc function. Let me go into detail:
For example this simple program:
volatile long m_Lock;
__int32 atomicInc(volatile long * val)
{
return _InterlockedIncrement(val);
}
int _tmain(int argc, _TCHAR* argv[])
{
atomicInc(&m_Lock);
return 0;
}
Lets compile with /FAs and inspect the assembler output:
; 13 : atomicInc(&m_Lock);
push OFFSET ?m_Lock@@3JC ; m_Lock
call ?atomicInc@@YAHPCJ@Z ; atomicInc
add esp, 4
atomicInc@@YAHPCJ@Z PROC ; atomicInc, COMDAT
; 7 : {
push ebp
mov ebp, esp
sub esp, 64 ; 00000040H
push ebx
push esi
push edi
; 8 : return _InterlockedIncrement(val);
mov eax, DWORD PTR _val$[ebp]
mov ecx, 1
lock xadd DWORD PTR [eax], ecx
inc ecx
mov eax, ecx
; 9 : }
pop edi
pop esi
pop ebx
mov esp, ebp
pop ebp
ret 0
The _InterlockedIncrement functions should not be wrapped. By wrapping them you are potentially losing atomicity. You should pray that your compiler optimizes your code and removes the atomicInc function call. (It probably will in Release mode) But keep in mind your code is not atomic at all. Here is what I am saying in laymens terms:
1.) The code you presented is not atomic.
2.) The compiler may optimize and fix the bug you have created.
Good Luck,
-David Delaune
|
|
|
|
|
If I understand correctly, you are suggesting the following sequence of events:
1) I call my wrapper method in thread1 passing &m_Lock, but somewhere prior to executing the atomic increment, there is a context switch to thread2.
2) Something in thread2 modifies the value of m_Lock, then switches control back to thread1
3) thread1 then increments the new value of m_Lock
Unless I am missing something, the critical section of these operations is still atomic. My method doesn't know what the value of m_Lock is, so whether I increment it before or after thread2 performs the modification is inconsequential. The only thing that could break this would be if &m_Lock is volatile, which could break the code even if calling the intrinsic directly.
Sure, my function won't necessarily be called and return without a context switch, but it doesn't effect (as far as I can tell) the correctness of the code. Is there something else I am still missing? Thanks for your help thus far,
Sounds like somebody's got a case of the Mondays
-Jeff
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
