|
yeah, it's rubbish, isn't it. pos_type has an int64 member, but there's no operator overload to get that out -only an int.
|
|
|
|
|
Hi!
I've received an error message:
1>e:\criccegui\main.cpp(75) : error C2661: 'CEGUI::SubscriberSlot::SubscriberSlot' : no overloaded function takes 2 arguments
1>e:\criccegui\main.cpp(76) : error C2661: 'CEGUI::SubscriberSlot::SubscriberSlot' : no overloaded function takes 2 arguments
1>e:\criccegui\main.cpp(77) : error C2661: 'CEGUI::SubscriberSlot::SubscriberSlot' : no overloaded function takes 2 arguments
1>e:\criccegui\main.cpp(78) : error C2661: 'CEGUI::SubscriberSlot::SubscriberSlot' : no overloaded function takes 2 arguments
The code corresponding to the error is:
play_btn->subscribeEvent(PushButton::EventClicked, Event::Subscriber(&InitialMenu::playHandler, this));
options_btn->subscribeEvent(PushButton::EventClicked, Event::Subscriber(&InitialMenu::optionsHandler, this));
credits_btn->subscribeEvent(PushButton::EventClicked, Event::Subscriber(&InitialMenu::creditsHandler, this));
exit_btn->subscribeEvent(PushButton::EventClicked, Event::Subscriber(&InitialMenu::exitHandler, this));
I've checked many time the function CEGUI::SubscriberSlot::SubscriberSlot() . It takes two arguments only.
How to resolve these errors?
|
|
|
|
|
OK, maybe I'm blind or undercaffienated but I'm not seeing any mention of SubscriberSlot(...) in the code you posted.
|
|
|
|
|
Sorry!
It's here. Actually I've to Subscribe to a member function.
template<typename T>
SubscriberSlot(bool (T::*function)(const EventArgs&), T* obj) :
d_functor_impl(new MemberFunctionSlot<T>(function, obj)) {}
another form:
template<typename T>
SubscriberSlot(const FunctorReferenceBinder<T>& binder) :
d_functor_impl(new FunctorReferenceSlot<T>(binder.d_functor))
{}
|
|
|
|
|
This is showing how SubscriperSlot is templated, but you need to post the code that declares one. Even better would be the code that actually generated the errors you showed.
Chris Meech
I am Canadian. [heard in a local bar]
In theory there is no difference between theory and practice. In practice there is. [Yogi Berra]
|
|
|
|
|
I am geeting error while lanching application
"mfc90.dll is not a valid Windows image. Please check this against your installation diskette. "
What is the issue?
|
|
|
|
|
john5632 wrote: mfc90.dll is not a valid Windows image
Replace with a new DLL(mfc90.dll). The Dll that you are using might be corrupted.
|
|
|
|
|
In addition on what Mohan said, also check for viruses.
That's a very common DLL, and looks strange it is "not a windows valid image".
2 bugs found.
> recompile ...
65534 bugs found.
|
|
|
|
|
Hi all,
I have a form view there I am having checkbox buttons.
Now i want to change the background color of the button.
I am using OnCtlColor() fn but it is not working.
|
|
|
|
|
Try this
CBrush m_brushBK;
In OnInitialUpdate function
m_brushBK.CreateSolidBrush(RGB(200,200,0));
In the OnCtlColor function
HBRUSH CtestDlg::OnCtlColor(CDC* pDC, CWnd* pWnd, UINT nCtlColor)
{
if(pWnd->GetDlgCtrlID()==IDC_CHECK1)
{
return m_brushBK;
}
else
{
HBRUSH hbr = CDialog::OnCtlColor(pDC, pWnd, nCtlColor);
return hbr;
}
}
|
|
|
|
|
OK thank you it is working
|
|
|
|
|
Hi all,
I have a camera service that records video to file running on windows mobile. But I will need to change it to record to buffer. It will be a service run in background.
And I may have some others application (on the same device) that need to access to this buffer and display the video in real time. I'm thinking about a RTSP server on mobile, but it will be very complex. So I just need a solution to transfer a video buffer between applications on the same device.
Can you give me any idea?
Thanks,
|
|
|
|
|
How about thorough a socket with TCP/IP or maybe UDP?
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
That's why I'm thinking about RTSP server. But it's too complex. I just need something simple
|
|
|
|
|
The other application(s) that would connect to your app, are those also written by you (so you can make up any way to connect you wish) or you want to do some generic, standardized way?
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
The other applications/clients could be written by me and could be write be someone else, we have some clients that will use this service. I prefer a standard way, but the speed is in priority (because these applications are for mobile phone). So I'm interested in a specific solution too.
|
|
|
|
|
Well, if you are allowed to come up with the protocol yourself then what's wrong with communicating through a socket? It shouldn't be that hard to come up with a simple, easty to implement way to connect and transfer data, of course i have no real overview of your project so i can't know.
Other methods that come to my mind are named pipes or shared memory, don't know if any of these is available on the mobile platform or not.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
I'm wondering about the speed, I need that should be in real time, like when you see the mobile phone camera.
I don't know if I have to compress video before send it to socket. If I have to, so I need to compress and decompress video, the speed will be slow, I think.
If I don't compress them, so the data packet should be very big, I don't know if I can make a stream.
I see that youtube, dailymotion ... doing a stream. So I think the 2nd solution should be ok. That why in the first post I talk about a simple RTSP server.
I prefer a common buffer/shared memory like when you make a communication between threads in one application, this solution is more efficient and simple. But I don't know if we can do the same way with some independent applications.
|
|
|
|
|
Hmm, i just checked the GlobalAlloc method and found out that GMEM_SHARE is obsolete and ignored by the method (and is provided for backwards compatibility with 16 bit windows), i guess i was living in the past, as i could have sworn this would still work. Anyways, here's[^] a list of (some) interprocess communication methods, maybe one of these could be used on a mobile device too.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
thanks your helpful reply
|
|
|
|
|
Yourwelcome, i hope it did help. Could you tell me (and others who are reading this conversation maybe) which method you decided to use? Just curious...
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
I'm thinking about Pipes, File Mapping and a simple rtsp server (it means that TCP/UDP). I will do a/some test and tell you (not now, but when I done the test) which one I will use.
If RTSP is "enough" simple, I prefer it, because it's a standard, so I can reuse for my other projects.
|
|
|
|
|
The "Using a File Mapping for IPC" part seems to be promising. (see the link in my other post)
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
|
Do you see the "reply" link, down to the message ??
If you want to thank someone, just "reply". Don't start a new thread for that.
Otherwise we cannot figure out what are you talking about to whom.
2 bugs found.
> recompile ...
65534 bugs found.
|
|
|
|