|
As previous poster, I'm not sure about your question. But my guess is , you are looking for something similar to Delay message Box[^], by Shog9, Nishant Sivakumar .
Prasad
MS MVP - VC++
|
|
|
|
|
Hi All!
I need your help for Digital Rights Management,I have sample Examples from Microsoft.But One of them is not working.and that is "UncompAVIToWMV".
its console application it is used for converting AVIToWMV. Even I am ready to provide the sample
for that.Can any body help me?
"Success lies not in the result , But in the efforts !!!!!"
Amit Mistry - petlad -Gujarat-India
|
|
|
|
|
Hi I am looking for a profiler for old MFC/WIN32 app in VS6 environment, Checking out BoundsChecker, it looks great (click to see profiler screen cap) and it seems to support VS6 with SP5 (system req here), but it seems to be a bit expensive (in my humble opinion, price list here[^]) and I need it fast (if free or cost very low enuf I can skip the normal purchasing process which takes too long), even if just an eval edition
Also checked out AQ Time, still costs US$500 - but it's pretty user friend and you can get up and running really fast.
Is there any alternative? Many thanks.
devy
|
|
|
|
|
Hi,
I've been coding for a while - and have used MFC in the past. I've run into a situation where I can't avoid using the Doc/View combination.
Here's where I'm having trouble. I built a mostly complete Sudoku game without the Doc/View classes, but now I am required to have Save and Print functionality - so I'm trying to switch the code over from just a MainFrame class to the Doc/View combo.
Most of it is translating OK, but I am having trouble with my CButtons. I can't get them to display. Where should I place the CButton btnTest.Create( /// ) code?
Any ideas?
Thanks in advance,
Walt
|
|
|
|
|
Walt Austin wrote: Where should I place the CButton btnTest.Create( /// ) code?
In a WM_CREATE handler (OnCreate()) for the parent window is a good place, after calling the base
class OnCreate(). That's the first chance you get with a valid parent HWND.
Switching to Doc/View architecture seems kind of extreme for save and print functionality IMO.
Whatever works I guess
"If you can dodge a wrench, you can dodge a ball."
|
|
|
|
|
|
Thanks for the link. I checked out the site, but can't seem to find an example where the doc/view is being used with CButtons. Actually I spent several hours yesterday looking on the web for an example of this - but never found one. Maybe I was looking in the wrong places?
Usually if I can see a single example of what I'm trying to do - it's a painless process from there on. Do you have an example that you could point me towards?
Thanks for the help,
Walt
|
|
|
|
|
Thanks for the suggestion.
I will try it later today.
Mark Salsbery wrote: Switching to Doc/View architecture seems kind of extreme for save and print functionality IMO.
Whatever works I guess
So - I saw an article for printing without the doc view, but originally thought that switching to the doc/view would be easier. Now I'm starting to change my tune. The doc/view feels pretty awkward to me, to be honest. I'll see if the print functionality could be done any simpler.
About the save - I could save my user data as a flat file, but were you refering to a Serialize function call? Just curious as to what you think is easier.
Big thanks for all of the help.
-Walt
|
|
|
|
|
Doc/View is fine if you're ok with being bound to it. It provides an object-oriented solution
to common document/view related tasks.
I'm just saying that if you have a program already up and running without it and you want to add
printing and saving then it could be a pain to change the architecture - maybe more trouble
than it's worth.
For saving, whatever format you want the file to be I suppose. Using MFC serialization may make
your file format too MFC specific - maybe you want the format to be easily usable in other
systems. If that's not an issue, the advantage is it's easy to implement and it comes with
built-in versioning on the serialized stream.
For printing, MFC has alot of handy code written for you for common tasks. The cool thing is
that the source code is there so you can pull stuff you need from it.
I guess it's always a trade off. I personally found that my projects that started with doc/view
got progressively harder to customize because my UI went a different direction than the way
doc/view does it. It's generally in my way these days. If I was writing a word processor it
would be great.
All just my opinions/rants
Mark
"If you can dodge a wrench, you can dodge a ball."
|
|
|
|
|
Walt Austin wrote: I can't get them to display.
Where?
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Here is some code I wrote that needs to be called from a Win32 exe. The Win32 exe needs to run on both 9x and NT platforms. The code compiles with no problem on VS 2005, but the DLL will not load when run in 9x.
It runs under NT, and only if I uncomment the "//return" line, will it run under 9x. LsaOpenPolicy is an NT platform API - it's as though the DLL is calling the LsaOpenPolicy even when blocked by an (if) statement on 9x. Is it something obvious I'm missing? I dont' want to create two DLLs, one for 9x and another for NT.
************************* DLL (host.dll) *************************
#include <windows.h>
#include <ntsecapi.h>
NTSTATUS GetLsa();
NTSTATUS ntsTemp;
BOOL bIsNTPlatform;
...
BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD dwReason, LPVOID lpvReserved)
{
OSVERSIONINFOEX osvi;
ZeroMemory(&osvi, sizeof(OSVERSIONINFOEX));
osvi.dwOSVersionInfoSize = sizeof(OSVERSIONINFOEX);
if (!GetVersionEx((OSVERSIONINFO *) &osvi))
{
osvi.dwOSVersionInfoSize = sizeof (OSVERSIONINFO);
if (!GetVersionEx((OSVERSIONINFO *)&osvi))
return FALSE;
}
bIsNTPlatform = (osvi.dwPlatformId == VER_PLATFORM_WIN32_NT);
if (bIsNTPlatform)
ntsTemp = GetLsa();
return TRUE;
}
NTSTATUS GetLsa()
{
LSA_HANDLE hPolicy = LSA_HANDLE(0);
LSA_OBJECT_ATTRIBUTES ObjectAttributes;
//return 1;
return LsaOpenPolicy(NULL, &ObjectAttributes, POLICY_VIEW_LOCAL_INFORMATION, &hPolicy);
}
************************* DLL (host.dll) *************************
************************* VB EXE that calls DLL *************************
Private Declare Function LoadLibrary Lib "kernel32" Alias "LoadLibraryA" (ByVal lpLibFileName As String) As Long
Private Sub Main()
MsgBox LoadLibrary(App.Path & "\host.dll"), , "LoadLibrary")
End Sub
************************* VB EXE that calls DLL *************************
|
|
|
|
|
Have you looked at the docs for LsaOpenPolicy ?
"Windows NT/2000/XP: Included in Windows NT 3.51 and later"
|
|
|
|
|
Yes, but I only call the function if bIsNTPlatform is TRUE.
|
|
|
|
|
But by linking to it, you're asking the loader to fixup the entrypoint when your DLL gets loaded. You could try using GetProcAddress() instead, using proper dynamic linking.
Steve S
Developer for hire
|
|
|
|
|
I'm confused, then, b/c the DLL _will_ load on 9x as long as there is a "return" before the NT-only API call.
And what do you mean by "proper"?
|
|
|
|
|
I'm not Steve, but I'll take a crack at explaining this. The fact that you have a return in your code before you call function X does not affect what the OS does when it tries to load your program. All it has is a list of functions that your program needs to run - that list is created when the program is linked together. If any function in that list is not available when the OS tries to load your program, it will fail.
Steve's use of the term "proper dynamic linking" is made to distinguish it from what you get when you use an import library. You link with the .lib and that .lib contains references to the DLL it is associated with. However, as you've found out, it creates dependencies on functions that you may not use _at execution time_. "Proper" does not create that dependency at the expense of making more work for you in your program. You'll need to do something like:
if os is nt or greater
{
LoadLibrary ("the name of the dll containing the function")
GetProcAddress (handle from LoadLibrary, "name of function");
(function pointer from GetProcAddress) (parameters to function)
}
else
{
whatever you do in the windows 95 and 98 case
}
This way, the function in question is not in the list of functions that the OS tries to resolve when your program is loaded.
Judy
|
|
|
|
|
Ohhhhh...ok. I will give that a try, then. Interesting that on 9x the code works if the "return 1" is uncommented, and fails when it is commented?
So like this?
typedef NTSTATUS (NTAPI *PLSAOPENPOLICY)(PLSA_UNICODE_STRING, PLSA_OBJECT_ATTRIBUTES, ACCESS_MASK, PLSA_HANDLE);
PLSAOPENPOLICY pLsaOpenPolicy = NULL;
h32 = LoadLibrary(TEXT("advapi32.dll"));
if (h32)
{
pLsaOpenPolicy = (PLSAOPENPOLICY) GetProcAddress(hAdvApi32,"LsaOpenPolicy");
pLsaOpenPolicy(NULL,&ObjectAttributes,POLICY_VIEW_LOCAL_INFORMATION,&hPolicy);
}
|
|
|
|
|
JeffRoz wrote: Interesting that on 9x the code works if the "return 1" is uncommented, and fails when it is commented?
My guess is that the compiler is optimizing the code and removing the call to the function since it is unreachable code with that return statement on the previous line.
JeffRoz wrote: h32 = LoadLibrary(TEXT("advapi32.dll"));
if (h32)
{
pLsaOpenPolicy = (PLSAOPENPOLICY) GetProcAddress(hAdvApi32,"LsaOpenPolicy");
pLsaOpenPolicy(NULL,&ObjectAttributes,POLICY_VIEW_LOCAL_INFORMATION,&hPolicy);
}
Make sure you check the return value from GetProcAddress and you should put () around pLsaOpenPolicy when you make the actual function call. Also, remember to call FreeLibrary when you are done with all the function pointers from the library.
Judy
|
|
|
|
|
Thanks so much for your help!
|
|
|
|
|
Couldn't I also just use the "Delay Loaded DLLs" in Visual Studio's Linker options?
|
|
|
|
|
I don'tknow - I've never used that linker switch. You'll have to give it a try and see if it works. My concern is if you use other functions in the DLL, will it try to link every function in that DLL that you may use. In other words, what will it do when it loads that DLL but doesn't find a member of the list of required functions in the DLL? The unsupported function is still going to be in the list, even with this linker option.
As I said, I've never used delayed loading and don't know the internals of how it handles the list of functions required. You're going to have to try it to see if it works.
Good luck. Let me know if it works - it would make life simpler. If it does work, check and see if you call other functions (at runtime) that are contained in the DLL, and post that info also.
Judy
|
|
|
|
|
I need to add a dialog to a project that only has available the Standard Windows Library.
I am at the point where the dialog displays and the progress bar updates. I need to add changing the text in a Label.
I don't know what command to send, and how to specify the text.
The dialog is created with:
<br />
HWND hwndProgressDialog = CreateDialog(hinstance,<br />
MAKEINTRESOURCE(IDD_DIALOG_EM),<br />
GetDesktopWindow(),<br />
EMProgressRoutine);<br />
Here is the code that updates the progress bar:
<br />
hwndProgressBar = GetDlgItem(hwndProgressDialog, IDC_PROGRESS_EM);<br />
SendMessage(hwndProgressBar, PBM_SETPOS, (WPARAM)ProgressCount, 0);<br />
To update the lable text, I assume I get a handle to the Label ID in similar fashion and do another SendMessage. But, what is the comparable command to PBM_SETPOS for setting text and how to specify the text itself?
Thanks for any help.
|
|
|
|
|
You can use the SetWindowText() API (or use a WM_SETTEXT message directly) to set a control's text.
Mark
"If you can dodge a wrench, you can dodge a ball."
|
|
|
|
|
Thank you, Mark. SetWindowText works. Can you tell me, if I used the WM_SETTEXT in a SendMessage, how would I specify the text?
|
|
|
|
|
Never mind. Figured it out.
|
|
|
|