|
Hi Friends,
I am creating software for creating fonts. Let me know wheather is there any SDK's for developing fonts for Microsoft Windows.
Thanks & Regards,
Promise
If you have faith in the cause and
the means and in God, the hot
Sun will be cool for you.
|
|
|
|
|
Hi guys,
is it possible to define partial specialisation for a class template that contains nontype parameter? I wrote a simple template example and wanted to do a specialisation for char * type. I couldn't figure out how to do it, any thoughts?
My original template class is below:
template<class kind, int stack_size>
class stack {
private:
int count;
kind data[stack_size];
public:
stack (void) {
count = 0;
}
void push (const kind item);
kind pop (void) {
--count;
return (data[count]);
}
};
With push() member function separately defined.
template<class kind, int stack_size>
inline void stack<kind, stack_size>::push(const kind item)
{
data[count] = item;
++count;
}
Now I tried to specialise the class for char *
template<int stack_size>
class stack<char *, stack_size>
{
private:
int count;
char *data[stack_size];
public:
stack (void) {
count = 0;
}
void push (const char *item);
char *pop (void) {
--count;
return (data[count]);
}
};
<br>
inline void stack<char *, stack_size>::push(const char *item) <---- error
{
data[count] = strdup(item);
++count;
}
The part above wouldn't compile properly. I got a compile error when it hits the push() function definition. It says the stack_size is undeclared identifier.
Thanks.
|
|
|
|
|
The correct syntax for the specialized member of stack::push is as follows:
template<int stack_size>
inline void stack<char*,stack_size>::push(const char* item)
{
...
}
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
Want a Boost forum in Code Project? Vote here[^]!
|
|
|
|
|
Thank you, Joaquín
In addition. You can see that only stack::push() was needed to change for the specialisation. I am wondering if the C++ template standard provides a way to directly make a specialisation towrds member functions, without having to rewrite whole class specialised declaration?
Thanks again.
|
|
|
|
|
No, you can't partially specialize a member function. The language allows you only to fully specialize a member function. For instance, the following is valid:
template<>
inline void stack<char*,1024>::push(char* const)
{
} but I'm afraid this is not what you're after, sorry.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
Want a Boost forum in Code Project? Vote here[^]!
|
|
|
|
|
I'm into new assignment of sending SMS to mobile phones, I'm just a beginner to this, so please advice me in this regard or send a Visual C++ code to do this and the hardware requirements in detail.
my name is junnybol, and i'm from curacao
|
|
|
|
|
Unfortunately, all free C/C++ libraries for mobile communications, that I know, are designed only for particular type and connection. So I'd like to know:
1. What type of mobile do you have (Siemens, Nokia...?)
2. How do you connect to the mobile (serial line, USB, Bluetooth?)
Robert-Antonio
|
|
|
|
|
The sending of sms must be through a gsm modem that is connected to de com-poort. And one of the important things is that every mobile can receive a sms via my application.
What i know is that u need to use AT-commands, but how in my application i don't know.
my name is junnybol, and i'm from curacao
|
|
|
|
|
Com-port => you need the serial communication library. There's plenty of free c++ serial communication libraries, try google.
For detailed info about AT commands see documentation for partial type of your mobile phone. For example, look at scmxx library for communicating with Siemens mobiles. You can read many useful commands from the scmxx source code . Good luck!
Robert-Antonio
"A piece of paper is an ink-lined plane.
An inclined plane is slope up.
A slow pup is a lazy dog.
Q.E.D.: A piece of paper is a lazy dog."
|
|
|
|
|
SMS sending is done via AT commands specified in the GSM 07.05 norm (google for that). Implementing this yourself is not terribly difficult, but it'll take you some time.
Googling for "GSM 07.05 source code" yields several results, among them Tutanhamon's article Send SMS via RS232 or SMS Gateway, in C#
[^]. Although it is in C#, I guess it won't be hard to translate the interesting stuff to C++.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
Want a Boost forum in Code Project? Vote here[^]!
|
|
|
|
|
Hi, I'm newbie with visual c++ and c++ in general. As I told in subject, I have serious troubles getting data saved from listctrl.
|
|
|
|
|
hi,
with listctrl you can get only the text of listctrl's items. GetItemText(...) - parameters of this functions depends of wich view u use listctrl(large icon, small icon, report view....). This func return text as a CString object which you can save it any where you want - in file, in database, in registry .......
|
|
|
|
|
Does anyone know how to remove a dialog box from an application.
clearly erasing it from the .rc file is not enough...
Keep it simple
|
|
|
|
|
Hi,
Delete the class (.cpp,.h) files, the resource, and all the files where it is referenced.
Sujan
|
|
|
|
|
well the problem i m facing is a little strange.....:'( ... the problem occurs in VC provided class called CPushRoutingFrame...the function is Pop().... and the exception is Access violation..
It occurs occasionally and best part is in an empty destructor of one of my Window class.
what could be the problem>>??? please help asap.
shoaib
Hell is full so i m back....
|
|
|
|
|
could you give the lines where the error occured ?
watch also the functions call stack to understand the reason of this exception...
TOXCCT >>> GEII power
|
|
|
|
|
Hi,
Have a look @ the callstack window. It may give more information.
Sujan
|
|
|
|
|
well looking at the call stack window didnt helped me much...the full call stack contents are as follows:
> mfc71ud.dll!CPushRoutingFrame::Pop() Line 759 + 0x3 C++
mfc71ud.dll!CFrameWnd::~CFrameWnd() Line 138 + 0xe C++
eOT802asud.dll!4c1445bf()
eOT802asud.dll!4c142e70()
eOT802asud.dll!4c133de8()
ElxAppExtDevud.dll!ECEditorMDIChildWnd::~ECEditorMDIChildWnd() Line 36 + 0x20 C++
ElxVisualPpfaud.exe!ECWndChildFrame::~ECWndChildFrame() Line 79 + 0x44 C++
ElxVisualPpfaud.exe!ECWndChildFrame::`scalar deleting destructor'() + 0x2b C++
mfc71ud.dll!CFrameWnd::PostNcDestroy() Line 213 + 0x1f C++
mfc71ud.dll!CWnd::OnNcDestroy() Line 848 C++
mfc71ud.dll!CWnd::OnWndMsg(unsigned int message=130, unsigned int wParam=0, long lParam=0, long * pResult=0x0012e7bc) Line 2023 C++
mfc71ud.dll!CWnd::WindowProc(unsigned int message=130, unsigned int wParam=0, long lParam=0) Line 1745 + 0x1e C++
mfc71ud.dll!AfxCallWndProc(CWnd * pWnd=0x028dd658, HWND__ * hWnd=0x002006b4, unsigned int nMsg=130, unsigned int wParam=0, long lParam=0) Line 241 + 0x1a C++
mfc71ud.dll!AfxWndProc(HWND__ * hWnd=0x002006b4, unsigned int nMsg=130, unsigned int wParam=0, long lParam=0) Line 389 C++
mfc71ud.dll!AfxWndProcBase(HWND__ * hWnd=0x002006b4, unsigned int nMsg=130, unsigned int wParam=0, long lParam=0) Line 209 + 0x15 C++
user32.dll!77d43a68()
user32.dll!77d43b37()
user32.dll!77d45b40()
user32.dll!77d45b5f()
esfl202asud.dll!4e065046()
esfl202asud.dll!4e064d47()
uxtheme.dll!5ad73c6e()
uxtheme.dll!5ad71b71()
esfl202asud.dll!4e064cea()
user32.dll!77d43a68()
user32.dll!77d4a8f9()
user32.dll!77d4450d()
user32.dll!77d4a15d()
ntdll.dll!77fb4da6()
user32.dll!77d4a191()
user32.dll!77d6399b()
user32.dll!77d639bd()
user32.dll!77d626f6()
user32.dll!77d43a68()
user32.dll!77d43b37()
user32.dll!77d45b40()
user32.dll!77d45b5f()
mfc71ud.dll!CWnd::DefWindowProcW(unsigned int nMsg=545, unsigned int wParam=2098868, long lParam=0) Line 1024 + 0x20 C++
mfc71ud.dll!CWnd::WindowProc(unsigned int message=545, unsigned int wParam=2098868, long lParam=0) Line 1746 + 0x1a C++
mfc71ud.dll!AfxCallWndProc(CWnd * pWnd=0x028a3c78, HWND__ * hWnd=0x00330542, unsigned int nMsg=545, unsigned int wParam=2098868, long lParam=0) Line 241 + 0x1a C++
mfc71ud.dll!AfxWndProc(HWND__ * hWnd=0x00330542, unsigned int nMsg=545, unsigned int wParam=2098868, long lParam=0) Line 389 C++
mfc71ud.dll!AfxWndProcBase(HWND__ * hWnd=0x00330542, unsigned int nMsg=545, unsigned int wParam=2098868, long lParam=0) Line 209 + 0x15 C++
user32.dll!77d43a68()
user32.dll!77d43b37()
user32.dll!77d4450d()
user32.dll!77d4453d()
ntdll.dll!77fb4da6()
user32.dll!77d45843()
user32.dll!77d4693b()
user32.dll!77d454cc()
mfc71ud.dll!CMDIChildWnd::MDIDestroy() Line 959 + 0x4c C++
mfc71ud.dll!CMDIChildWnd::DestroyWindow() Line 449 C++
ElxVisualPpfaud.exe!ECWndChildFrame::DestroyWindow() Line 748 C++
mfc71ud.dll!CFrameWnd::OnClose() Line 851 C++
ElxAppExtDevud.dll!ECEditorMDIChildWnd::OnClose() Line 122 C++
ElxVisualPpfaud.exe!ECWndChildFrame::OnClose() Line 177 + 0xb C++
mfc71ud.dll!CWnd::OnWndMsg(unsigned int message=16, unsigned int wParam=0, long lParam=0, long * pResult=0x0012f3b4) Line 2023 C++
mfc71ud.dll!CWnd::WindowProc(unsigned int message=16, unsigned int wParam=0, long lParam=0) Line 1745 + 0x1e C++
mfc71ud.dll!AfxCallWndProc(CWnd * pWnd=0x028dd658, HWND__ * hWnd=0x002006b4, unsigned int nMsg=16, unsigned int wParam=0, long lParam=0) Line 241 + 0x1a C++
mfc71ud.dll!AfxWndProc(HWND__ * hWnd=0x002006b4, unsigned int nMsg=16, unsigned int wParam=0, long lParam=0) Line 389 C++
mfc71ud.dll!AfxWndProcBase(HWND__ * hWnd=0x002006b4, unsigned int nMsg=16, unsigned int wParam=0, long lParam=0) Line 209 + 0x15 C++
user32.dll!77d43a68()
user32.dll!77d43b37()
user32.dll!77d45b40()
user32.dll!77d45b5f()
esfl202asud.dll!4e064f17()
esfl202asud.dll!4e064cea()
user32.dll!77d43a68()
user32.dll!77d43b37()
mfc71ud.dll!CThreadSlotData::GetThreadValue(int nSlot=0) Line 269 C++
user32.dll!77d4450d()
user32.dll!77d4453d()
ntdll.dll!77fb4da6()
user32.dll!77d45843()
user32.dll!77d45396()
user32.dll!77d45210()
user32.dll!77d452e8()
user32.dll!77d458e6()
uxtheme.dll!5ad73f9b()
uxtheme.dll!5ad8aad7()
uxtheme.dll!5ad71ae1()
uxtheme.dll!5ad71b48()
user32.dll!77d45a7b()
user32.dll!77d45d31()
user32.dll!77d59d13()
user32.dll!77d62710()
mfc71ud.dll!CMDIChildWnd::DefWindowProcW(unsigned int nMsg=274, unsigned int wParam=61536, long lParam=2753532) Line 433 C++
eOT802asud.dll!4c1436e8()
mfc71ud.dll!CWnd::Default() Line 275 C++
mfc71ud.dll!CWnd::OnSysCommand(unsigned int __formal=61536, unsigned int __formal=61536) Line 436 + 0xf C++
mfc71ud.dll!CFrameWnd::OnSysCommand(unsigned int nID=61536, long lParam=2753532) Line 1047 C++
ElxAppExtDevud.dll!ECEditorMDIChildWnd::OnSysCommand(unsigned int nID=61536, long lParam=2753532) Line 178 C++
mfc71ud.dll!CWnd::OnWndMsg(unsigned int message=274, unsigned int wParam=61536, long lParam=2753532, long * pResult=0x0012fb44) Line 2051 C++
mfc71ud.dll!CWnd::WindowProc(unsigned int message=274, unsigned int wParam=61536, long lParam=2753532) Line 1745 + 0x1e C++
mfc71ud.dll!AfxCallWndProc(CWnd * pWnd=0x028dd658, HWND__ * hWnd=0x002006b4, unsigned int nMsg=274, unsigned int wParam=61536, long lParam=2753532) Line 241 + 0x1a C++
mfc71ud.dll!AfxWndProc(HWND__ * hWnd=0x002006b4, unsigned int nMsg=274, unsigned int wParam=61536, long lParam=2753532) Line 389 C++
mfc71ud.dll!AfxWndProcBase(HWND__ * hWnd=0x002006b4, unsigned int nMsg=274, unsigned int wParam=61536, long lParam=2753532) Line 209 + 0x15 C++
user32.dll!77d43a68()
user32.dll!77d43b37()
user32.dll!77d45b40()
user32.dll!77d45b5f()
esfl202asud.dll!4e064f17()
mfc71ud.dll!CWnd::AttachControlSite(CHandleMap * pMap=0x002006b4) Line 445 + 0x16 C++
esfl202asud.dll!4e064cea()
user32.dll!77d43a68()
user32.dll!77d43b37()
user32.dll!77d43d91()
user32.dll!77d43df7()
mfc71ud.dll!AfxInternalPumpMessage() Line 188 C++
mfc71ud.dll!CWinThread::PumpMessage() Line 916 C++
mfc71ud.dll!CWinThread::Run() Line 637 + 0xb C++
mfc71ud.dll!CWinApp::Run() Line 701 C++
mfc71ud.dll!AfxWinMain(HINSTANCE__ * hInstance=0x00400000, HINSTANCE__ * hPrevInstance=0x00000000, wchar_t * lpCmdLine=0x0002078c, int nCmdShow=1) Line 49 + 0xb C++
ElxVisualPpfaud.exe!wWinMain(HINSTANCE__ * hInstance=0x00400000, HINSTANCE__ * hPrevInstance=0x00000000, wchar_t * lpCmdLine=0x0002078c, int nCmdShow=1) Line 25 C++
ElxVisualPpfaud.exe!wWinMainCRTStartup() Line 390 + 0x39 C
kernel32.dll!77e814c7()
The following is the code where exception occurs...
<br />
void Pop()<br />
{<br />
ASSERT( pThreadState != NULL );<br />
ASSERT( pThreadState->m_pPushRoutingFrame == this );<br />
pThreadState->m_pRoutingFrame = pOldRoutingFrame;<br />
pThreadState->m_pPushRoutingFrame = pOldPushRoutingFrame;<br />
pThreadState = NULL;<br />
}<br />
do reply if u get any thing out of this...
shaoib
|
|
|
|
|
|
Looks like a useful call stack to me. Can't you just doubleclick on the pop statement within the call stack and have visual studio point you to the line of code in the software? If what you have shown me is the complete function, then I assume that one of the ASSERT inputs is evaluating to zero. I would have no idea why this would be but that is probably what is happening. Since I can't see your whole implementation and have no idea what a routing frame is used for in the context of your system, you'll have to research why pThreadState == NULL or why pThreadState->m_pPushRoutingFrame != this. One of those conditions is probably be causing the program to halt since that is the function you've shown me the crash occurs in.
Simply assigning variables wouldn't cause a crash unless another thread within the system is trying to access the routing frame pointers while you are making the pointer swaps. This is another thing to look into. Since you obviously are using threads AND I don't see the use of a CMutex or CCriticalSection, you have to check and see if you have thread conflicts. Is it possible that the pop function is getting interrupted while you are reassigning the pointer values? Perhaps another thread is trying to use the pointer before the pop function is finished. But then if that were the case, I'd expect the debug crash to occur in another function or class. Weird; but swapping pointers like you are when running in a multithreaded system is very dangerous and the CCriticalSection and CMutex classes should be used to protect your software from erratic behavior.
Regards,
Shawn
|
|
|
|
|
hi 2 all,
well the issue is still not understood by me.... the only problem is that .... as far as my app being multithreaded is conserned i dont think thats an issue, the problem is as u must have seen, that the code crashes in a destructor... of CFrameWnd derived class...:'( well, as far as i get from my research this problem has something to do with dll's loading and thread states... well if any one know anything about it.... do reply asap.
|
|
|
|
|
You never gave us the code for the destructor. Again, the call stack looks pretty plain to me. It's telling you exactly where the crash occurred. Without being able to look over your shoulder and step through your source code, there isn't a whole lot anyone else can do. IF it crashes in the destructor, why is the last call stack statement in the pop function?? My assumption is that the pop was where the crash occurred since that is where the program appears to have halted and this is the code fragment you gave us. While you are running in debug mode, are you able to step through the code right before the crash? WHen the system does crash, you should be able to double click on each statement in the call stack and perform an analysis of variable states; look for NULL pointers and test the assert conditions, etc. Consider yourself lucky to have a call stack that points directly at your code. Many times, you get call stacks that are pointing to MFC code which is really hard to troubleshoot.
Shawn
|
|
|
|
|
well i think i mentioned in one of my post that the code crashes some where IN THE MFC Code... the pop function i gave you was from afxpriv.cpp and it is an MFC file... one more thing as i mentioned back that the assert IS because of a NULL pointer... but i dont have a clue y its NULL.. cuz it have something to do with AFX_MANAGE_STATE... and sh*t like that... MSDN doesnt give any info about it...
and again the best part is that it crashes occasionally..... not always... there is NO threads in my App.
well i didnt get anything out of it... hope you can help me with AFX_MANAGE_STATE ....or something like that.
as for your query... the last call at the stack is Pop cuz it is automatically called after a CFramewnd derived object is Destroyed using DeleteWindow which removes the current frame from the RoutingFrame stack.
shoaib.
|
|
|
|
|
Hi !
I was writing a mailsync module for MSO and i am quite bewildered with one thing.
We use mapilogonEx() ( or initesession() as in ur program ) to login to a profile.Now generally speaking , profiles are not password protected.So, after logging in to a profile , I am able to fetch the messages WITHOUT supplying a password ? ! I mean if i had to retrieve from the server , then OK the user might put in some prompt for password or something , but what about the already downloaded messages ? I am able to view them all the same ?!So i guess the only way to be safe is by password protecting a .pst file....what do you think ?
Thanks,
Best Regards,
Kane
"Some guys hack just to get themselves a girlfriend.What a pathetic reason huh ?"
|
|
|
|
|
whoops ..just ignore what i said about initesession..mapilogonex is the only way...but still the question stays ..
-kane
"Some guys hack just to get themselves a girlfriend.What a pathetic reason huh ?"
|
|
|
|
|