|
When you create a file over the network there's loads of things that can go wrong - the OS has got to wait a while to see if the remote system responds before failing.
There's probably not a lot you can do to speed things up, but there's a couple of tricks that can work.
First one is to do the opening assynchronously. Spin off a thread and use a future to signal when the file's open. If you can reorder your logic a bit so you start opening the file, process what you can in memory then write to the file when it's open you might be able to make it look like the file open opened quicker.
The second one only works if you know you're going to want to open the file well in advance of needing to use it. Just open the file as one of the first things your program does. When you need the file just open it again. This uses the fact that most OS filesystems are better at reopening already open files as it just needs to duplicate the file handle. Of course if you don't know what the file is well in advance this is absolutely no use to you whatsoever.
Cheers,
Ash
|
|
|
|
|
Any has any experience with these two?
I searched throughout the Internet for some getting started/tutorial/documentation for libmms but found absolutely nothing.
ffmpeg is a bit better documented, but I want to go one step at a time... I need to get the stream first...
We are using Linux daily to UP our productivity - so UP yours!
|
|
|
|
|
Hi,
I have to create a dll file to bind all the source code in a sinle library to ease of use.
For which dll I should go for
1. Regular DLL using shared MFC DLL
2. Regular DLL with MFC statically linked
3. MFC extension DLL
|
|
|
|
|
Why don't you create a .lib file instead ? If the only purpose is to "bind all the source code in a single library", then I would opt for a static library.
|
|
|
|
|
for size constraint and MFC classes uasge, I am looking going for MFC Ext dll.
|
|
|
|
|
you can reduce size of DLL, by eliminating not required library files, search CP for same
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
john5632 wrote: 1. Regular DLL using shared MFC DLL
2. Regular DLL with MFC statically linked
almost same, but 2 one would be bulky in comparison of 1, as MFC dll would be statically linked.
MFC extension dll can be used only with MFC application! rest can be used with n number of lanaguage
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
I am able to build MFC Ext DLL. I also intergarte .h,.lib and .dll files in my application and working fine. But my worry is..I have almost 15 file (.h and .cpp) which is need to be placed inside dll file.
Is there any solution that I am able to add only single .h file for all .cpp file.
If yes then how to do?
|
|
|
|
|
It all depends what you're trying to achieve. MFC extension DLLs do what they say on the tin, they extend MFC and you can't use it in application if the application's not MFC. So if you don't want to write an MFC app then this choice isn't for you!
Regular DLLs can be called by any application. They expose a C or C++ interface that doesn't use MFC in the interface. You can still use MFC internally though, in the implementation. If you want you code callable by non-MFC apps use a regular DLL (say you implement a control using MFC but give it a fairly bog standard message interface, or you're insane and for some reason like CString).
The final choice is whether to link MFC statically or dynamically. Linking statically increases the size of your DLL but means you won't have to ship an MFC DLL with your app (or use the merge module in your installer). This makes it a bit more self contained. However even using a simple window class can be quite costly in terms of what MFC stuff your DLL has to drag in to do it's stuff. If you link dynamically your DLL will be smaller but you'll have to ship another stonking great DLL. If you're already shipping the MFC DLL for another nefarious purpose it's a no brainer, link dynamically. Otherwise build both ways and see which gives you a size you're happy with.
Cheers,
Ash
|
|
|
|
|
Hi, every one,
when i do encrypt, i meet some problem, if somebody who meet this kind of problem,can you tell me how to solve this problem, thank you!
First: I write a encrypt funtion using C++, and after I get the asymmetric key pair, then I want to save the key to the key store, in C++, I did not find such of function. But under .NET, there is a class named CspParameters, it can save a key to a container, all the code I see is below:
int main()
{
// creates the CspParameters object and sets the key container name used to store the RSA key pair
CspParameters^ cp = gcnew CspParameters;
cp->KeyContainerName = "MyKeyContainerName";
// instantiates the rsa instance accessing the key container MyKeyContainerName
RSACryptoServiceProvider^ rsa = gcnew RSACryptoServiceProvider( cp );
// add the below line to delete the key entry in MyKeyContainerName
// rsa.PersistKeyInCsp = false;
//writes out the current key pair used in the rsa instance
Console::WriteLine( "Key is : \n{0}", rsa->ToXmlString( true ) );
}
My qusetion is :
If I donot use the CspParameters class, how can I save the key pair to the key store using C++,if donot have this kind of function , how can i save my key pair, but not saved to BLOB.
Thank you very much!
|
|
|
|
|
Hi,
I drived a class from CStaic. Now I am using this new class for static control.
I am facing problem to draw the color on backgroung, I tried OnCtlColor() but breakpoint is not coming in this function.
What might be the cause?
|
|
|
|
|
Am not sure i completely understand what you are trying to do but check out this[^], if i am correct than it should help (you will need ON_WM_CTLCOLOR_REFLECT for your case i belive). Good luck.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Computers are evil, EVIL i tell you!! <
|
|
|
|
|
john5632 wrote: I am facing problem to draw the color on backgroung, I tried OnCtlColor() but breakpoint is not coming in this function
are you redrawing in you main dialog? or in staticcontrol derived class
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
Hi,
I have a problem in resolving the issue of GetFont() used in dialog box class for getting font but its returning NULL in one of the dialog class but its working in all the other dialog box classes.. The error comes in using the getlogfont() function where it crashes.. What could be the problem as it works fine in other dialog classes ... ?? please reply soon ...
modified on Monday, May 31, 2010 2:14 AM
|
|
|
|
|
it very dificult to answer without look on your code, where it failing!
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
the code which i am using is
CWnd* p_Wnd;
CFont* pFont;
pFont = p_Wnd->GetFont();
LOGFONT m_lFontBold;
pFont->GetLogFont(&m_lFontBold);
I am getting error in getlogfont in debugging mode. As far my understanding the getfont() isn't returning the handle to the object that is why there is an assertion problem in getlogfont(). But the same code is working properly in different dialog boxes.
|
|
|
|
|
pleaz use a valid CWnd* p_Wnd...
p_Wnd = this;
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
If you check the documentation[^] for WM_GETFONT (CDialog's GetFont is a wrapper around that), a NULL value means your dialog is using the system font. Otherwise, if you are not testing this in debug mode (so you don't get a debug assert) then you simply get a NULL back if you call GetFont on a dialog that has not been created, as far as i know at least. (Ok, if you run it in debug you still get the NULL back if your dialog wasn't created, but you would also get a DEBUG ASSERT FAILED notification...)
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Computers are evil, EVIL i tell you!! <
|
|
|
|
|
the code which i am using is
CWnd* p_Wnd;
CFont* pFont;
pFont = p_Wnd->GetFont();
LOGFONT m_lFontBold;
pFont->GetLogFont(&m_lFontBold);
I am getting error in getlogfont in debugging mode. As far my understanding the getfont() isn't returning the handle to the object that is why there is an assertion problem in getlogfont(). But the same code is working properly in different dialog boxes.
|
|
|
|
|
In the code you have shown you never initialize p_Wnd to anything...but i will assume that in the actual code segment you do. So what is the difference between this dialog and the others? How do you create it? When/Where do you ask for its font?
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Computers are evil, EVIL i tell you!! <
|
|
|
|
|
I am using this code in oninitdialog function to set up the bold font on initialization of dialog. There is no difference in other dialog boxes and this one for setting up the fonts. I havent initialized the pWnd in this code and in any other initdialog functions but still that works.
|
|
|
|
|
I have attached the control of dialog box to the cwnd object using getdlgitem()..
|
|
|
|
|
So you say you call GetFont thorough an uninitialized pointer and it works???? That doesn't sound normal...
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Computers are evil, EVIL i tell you!! <
|
|
|
|
|
hey i have initialized the cwnd object by passing the control of the dialog box static text using getdlgitem() function
|
|
|
|
|
And you did the same thing in all your dialogs, retrieve the handle of a static on the dialog in OnInitDialog, attach a CWnd to it, call GetFont on it, and it gave you a valid CFont pointer except for this one, identically implemented dialog? Can't think of anything smart, sorry...maybe someone else has a better response then.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Computers are evil, EVIL i tell you!! <
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
