|
Thanks for your help.
CryptoAPI is complicated to understand.
|
|
|
|
|
I try to compile an application ( SDI kind ) , to a fresh installed XP system , but I front with an link error :
LINK : fatal error LNK1104: cannot open file "libcmt.lib"
what I missing ? Can you help me , please ?
|
|
|
|
|
Find the lib file using search and make sure it's in your lib directory or path.
|
|
|
|
|
I do that , and I didn't find it ...
|
|
|
|
|
This[^] seems to suggest the file isn't present by default on a Windows or Windows+Visual system.
|
|
|
|
|
I install CRT static libraries and it work it . Thank you all.
|
|
|
|
|
Hi!
I've migrated a project form VC++ 6.0 to 2010 and find that some dialogs assert when they are created.
It happens inside CDialog::OnInitDialog(), more specifically inside CWnd::ExecuteDlgInit(). A resource
is found with the id that corresponds to the dialog resource, it's loaded, locked and CWnd::ExecuteDlgInit
is called again with a pointer to the resource. This second call to ExecuteDlgInit asserts in this line:
ASSERT(nMsg == LB_ADDSTRING || nMsg == CB_ADDSTRING ||
nMsg == CBEM_INSERTITEM || nMsg == WM_MFC_INITCTRL ||
nMsg == WM_OCC_LOADFROMSTREAM ||
nMsg == WM_OCC_LOADFROMSTREAM_EX ||
nMsg == WM_OCC_LOADFROMSTORAGE ||
nMsg == WM_OCC_LOADFROMSTORAGE_EX ||
nMsg == WM_OCC_INITNEW);
It happens with some of the project's dialogs, not in all of them... I'm at a complete loss.
Any one has dealt with this?
Thanks,
Aritosteles
|
|
|
|
|
Check the value of
nMsg to see what Windows is complaining about. Also make sure that you have done a complete rebuild of your project under the new environment.
Just say 'NO' to evaluated arguments for diadic functions! Ash
|
|
|
|
|
Hello folks!
I have a small project in mind which would involve creating virtual files/folders on a client's computer (preferably without needing admin rights too). My first thought was to create a shell extension, however, here[^] MSDN doesn't list anything like virtual folders or files. Then i moved on to creating a File System Minifilter Driver[^], but this seems to be overkill for this purpose only. After some googling i came accross the Installable File System kit[^], but checking it on Microsoft's site i found this:
If you are trying to create virtual files or directories to be viewed through the Windows Shell, the shell extension interfaces may be a better option. Shell extension modules are user-mode DLLs that are registered with the Windows Shell. For more information on these interfaces, please refer to the Platform SDK section of the MSDN Online Library..
So now i am confused, it suggests to use shell extensions, however, shell extensions doesn't seem to provide this functionality...where did i go wrong? Anyone can give me some pointers, please? Thanks in advance...
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Leela: Fry, you're wasting your life sitting in front of that TV. You need to get out and see the real world.
Fry: But this is HDTV. It's got better resolution than the real world <
>Nothing is free in the universe.<
|
|
|
|
|
I've been looking into a similar thing.
The best I've come up with so far is Doken[^].
They have developed the kernel driver and expose a user API to develop your own filesystem apps.
Others have already developed both ram and file based filesystems[^] for it.
The minifilter option provides filesystem access for _all_ applications, shell extensions are only for accessing files through, well, the shell e.g. explorer.
It comes down to how will the client need to interact with your filesystem ?
...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
|
|
|
|
|
Thanks for your reply. This is what i'd like to do: the user would "mount" the filesystem on his computer by running a small program or somesuch. A new drive would appear on his system or a new folder would pop up on his desktop (i'd prefer the new drive as if an USB storage device had been connected). Either way, i will call this the "root". So under the root, some folders and files would appear. The content of some folders and files the user should be able to modify, some not. For example he should be able to edit some files, but not delete them, he should also be able to open some files for reading but not save them (he can save them to a different location if he wishes to of course but not overwrite the originals), he should be able to add new files in some folders or delete them, but not be able to do the same in some other folders. Here comes the more tricky part: these files and folders don't really exist on the user's computer, hence, "virtual files and folders". The files' contents are generated/converted on-the-fly, what i mean is, the user e.g. sees abc.doc on the drive, opens it with Word, the system, "behind the scenes", generates the doc format data from other kind of data that might come from a database or another file, etc., the user edits the contents and when he saves it, the doc is converted back to the original data format and stored back into the database or to the other file or wherever it came from (also, possibly over a network/internet).
I really suck at explaining things but i hope it's clear what i mean. I guess i will have to dig deep into writing a file system driver if i want to make anything of this. I will check out that Dokan, looks promising.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Leela: Fry, you're wasting your life sitting in front of that TV. You need to get out and see the real world.
Fry: But this is HDTV. It's got better resolution than the real world <
>Nothing is free in the universe.<
|
|
|
|
|
I believe I understand, it's similar to what I'm looking to do - be able to mount new drives that expose filesystems stored in a database.
I think Doken will be the easiest and most flexible solution.
If you look through the source of the ones implimented on their site you'll see it's not too bad.
...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
|
|
|
|
|
Thank you for the help and good luck with your own project.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Leela: Fry, you're wasting your life sitting in front of that TV. You need to get out and see the real world.
Fry: But this is HDTV. It's got better resolution than the real world <
>Nothing is free in the universe.<
|
|
|
|
|
When looking at shell namespace extensions (which can't serve this purpose) i came across another idea, faking a remote filesystem that can be mounted as a network drive. Doing this seems to be less troublesome than writing a file system driver from scratch, am still trying to evaluate this idea, might or might not work, i just thought i mention it since you said you are looking for something similar too.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Leela: Fry, you're wasting your life sitting in front of that TV. You need to get out and see the real world.
Fry: But this is HDTV. It's got better resolution than the real world <
>Nothing is free in the universe.<
|
|
|
|
|
As far as I can tell, you have to write code to handle file CRUD requests no matter how you do it ... six of one, half-dozen of the other.
So far the Dokan still looks easiest, it looks like the main dev points are:
1. Write thread-safe functions specified in DOKAN_OPERATIONS e.g. CreateFile, ReadFile, ...
2. Pass an instance of DOKAN_OPERATIONS with pointers set to your functions, and DOKAN_OPTIONS with info on how you want to mount your FS, to the driver via DokanMain. This will also mount your FS.
3. Call DokanUnmount when done with FS.
I still have to work through the nuances of mounting/unmounting via: my app, dokanctl, dokan mounter, ...
Notes:
- Although Dokan comes with both x86 and x64 drivers, it looks like the user dll is x86. This means your app must be compiled for x86.
- The Dokan API does support files > 2GB.
- Test your app FS in a virtual machine, if you made a mistake it can totally hose your system.
...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 have two concerns about Dokan:
-you have to install its driver as administrator
-even when you do not use it for anything it still lingers around
I guess these are minor concerns though. I read some SMB (NetBIOS) specs and realized it indeed seems to be way way too complex for this.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Leela: Fry, you're wasting your life sitting in front of that TV. You need to get out and see the real world.
Fry: But this is HDTV. It's got better resolution than the real world <
>Nothing is free in the universe.<
|
|
|
|
|
The fact that it's open source alleviated any concerns about installing as admin ... or do you mean concerns for deploying to your customers ... yes, I could see that being an issue.
I don't think it uses much when idle ... on my machine the mounter service is using 928KB, 71 handles, and 4 threads with no FS mounted.
I am more concerned about the fact that it's open source means I have no idea how rigorous the testing has been on the code; however, it seems to be used by others who are providing commercial products that use it, so it can't be that bad.
For me it's a good starting point. I can focus on the FS part of the code. Later if I find bugs in dokan, want more performance, want more control, then I can look at writing the kernal part myself.
...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: The fact that it's open source alleviated any concerns about installing as admin ... or do you mean concerns for deploying to your customers ... yes, I could see that being an issue.
-that's what i meant
About the lingering, it's really nothing serious, it's just an "eccentric" thing of me, i can live with it.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Leela: Fry, you're wasting your life sitting in front of that TV. You need to get out and see the real world.
Fry: But this is HDTV. It's got better resolution than the real world <
>Nothing is free in the universe.<
|
|
|
|
|
What you are looking for is not an shell extension handler, but a shell namespace extension:
MSDN 1[^]
MSDN 2[^]
CodeProject[^]
It's been years since I looked into this, and at least back then, it was a pain - lots of low level COM handling, lots of unexpected (and unexplained, but probably necessary) behavior on the side of explorer, etc. However, I've seen better samples and utilities that make that easier.
|
|
|
|
|
I'll check this option too, thank you very much.
[EDIT] So i googled around some and found out that namespace extensions won't do for my case, e.g. here[^] they talk about it, you can's load/save the virtual items in a namespace extension (only by some hacky means), if you read my other post here[^], you'll understand what i mean.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Leela: Fry, you're wasting your life sitting in front of that TV. You need to get out and see the real world.
Fry: But this is HDTV. It's got better resolution than the real world <
>Nothing is free in the universe.<
modified on Wednesday, December 29, 2010 8:07 AM
|
|
|
|
|
The find in files toolbar disappeared.How could I get it back? I could only use the menu or "ctrl+shift+F" now.
Microsoft Visual Studio 2005
Version 8.0.50727.42 (RTM.050727-4200)
Microsoft .NET Framework
Version 2.0.50727 SP1
|
|
|
|
|
Right click on your toolbar and select the options you want.
Just say 'NO' to evaluated arguments for diadic functions! Ash
|
|
|
|
|
In dialog box application i remove system menu(close,minimize and maximize buttons and title bar) from dialog.Add my own button for minimize. And write code for button click SENDmESSAGE(ws_minimize,0,0). After clicking on button dialog hides from desktop but does not appear on task bar. How to show the exe icon at task bar.
Since title bar is removed how to drag the dialog if i have any label at top top of dialog.
|
|
|
|
|
i didn't understand fully ur question,anyway check out the WM_NCHITTEST message.you can make ur windows client area as a titlebar easily with this.
hopes this helps
If u can Dream... U can do it
|
|
|
|
|
Thanks
NCHITTEST works fine.
About the first problem let me explain.
I create a dialog base application. on first dialog there is a button. When i click on that button, i display second dialog and hide first dialog. When second dialog display and i minimize it, the exe does not display at task bar. Can i do something to display exe at task bar for that case?
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
