|
I need to know how to control a directory structure from the "Open" dialog window from an application. I need to be able to restict the user from going to directories that have been determined they should not enter and restrict them to a certain directory. Anyone have any idea how to do this not in MFC, win32 api format.
Thanks,
|
|
|
|
|
You can restrict them to a single directory using the OFN_NOCHANGEDIR flag. If you need something a little more complicated then create your own OpenFile dialog.
|
|
|
|
|
waldermort wrote: You can restrict them to a single directory using the OFN_NOCHANGEDIR flag.
Wrong. That flag restores the current directory to its original value if the user changed the directory while searching for files.
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"There is no death, only a change of worlds." - Native American Proverb
|
|
|
|
|
Thanks for pointing that out, learn something new everyday :->
|
|
|
|
|
See here.
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"There is no death, only a change of worlds." - Native American Proverb
|
|
|
|
|
the hard way would be hooking ZwQueryDirectoryFile and restricting your diretories.
:P
I'm sure there is an easier way
gabby
|
|
|
|
|
Here is the scenario.
I have a web based email client application I have created on a certain website. Whenever a user clicks on an email address, it will take them to this client and populate the TO field, and maybe even the subject field, depending on the mailto parameters.
I know I'd have to set my default client to this web based client. Does anyone know how to accomplish this or any direction I can be pointed to, to begin? What tools should I use?
-- modified at 16:39 Wednesday 5th April, 2006
|
|
|
|
|
I suspect you'd need to make a change to HKEY_CLASSES_ROOT\mailto\shell\open\command.
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"There is no death, only a change of worlds." - Native American Proverb
|
|
|
|
|
Yea. I know you have to change the to open Internet Explorer and set it to the respective URL. However, how would you populate the form's fields?
|
|
|
|
|
One way is via the mailto: protocol itself:
mailto:tdnxxx444@codeproject.com?Subject=Test subject&Body=Test body
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"There is no death, only a change of worlds." - Native American Proverb
|
|
|
|
|
How would I use the that populate the fields in my WEB BASED email client that I wrote though?
|
|
|
|
|
It looks as though I spoke too soon. You may have to resort to some .vbs, .wsh, or .js file to do this for you.
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"There is no death, only a change of worlds." - Native American Proverb
|
|
|
|
|
Okay. Where would the above file you mentioned be locationed? On my website with the email client?
I looked at how they do it for the hotmail client that is built into internet explorer and it seems to use a DLL file. Would this way be easier or the way you mentioned?
This is basically how the flow of events should look so that we are on the same page:
user clicks on mailto hyperlink in their browser ->
another internet explorer opens up and takes them to our website email client application ->
form is populates TO: and SUBJECT: fields based on the paramaters of the mailto hyperlink
I guess I am confused as to how the "mailto" hyperlink would communicate to internet explorer and to our website that the user is taken to, these respective parameters.
|
|
|
|
|
tdnxxx444 wrote: Okay. Where would the above file you mentioned be locationed? On my website with the email client?
Ignore my earlier suggestion.
tdnxxx444 wrote: I looked at how they do it for the hotmail client that is built into internet explorer and it seems to use a DLL file.
I'm sure that IE uses dozens of DLL files. That sort of goes without saying.
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"There is no death, only a change of worlds." - Native American Proverb
|
|
|
|
|
hey, I am almost certain that the problem with my dll at this point is an access violation caused by writting to a file. I have stripped out all other code but that, and it fails, I strip out just that and the rest succeeds. So, I know it is with the writting to the file, which is causing an access violation.
I placed returns strategically through out the source and I know that it is behaving accordingly as planned and should not cause a violation, however, it is.
I have a setup similar as follows:
while (blah is blah) { // run till judgment day
out = fopen("test.txt", "a");
for (blah = 0 to length of header) { // loop till blah equals header length
fprintf(out, some data)
}
fclose(out);
} // end while
and that is pretty much it, in a nutshell. The problem is unknown to me, because this works fine in an exe I built --I am trying to port my code to dll.
I am starting to think that I can NOT work with a dll like I could a VB module. It seems the minute I start to write to the file, it will loop through the for 5 times and then crash, if I don't loop, it will write one time just fine.
I hope that I haven't explained all help away and that my question is clear. I need to find out why I can not continously write to a file from a DLL. Why it is causing an access violation, per debug. And what I can do to fix it or if I should stop trying to do the impossible --I assume at this point that this is impossible to accomplish from a DLL.
If you need more info, please let me know. I thank you in advance.
-- modified at 13:41 Wednesday 5th April, 2006
bold = modified
|
|
|
|
|
borono wrote: out = fopen("test.txt", "a");
Why are you opening the file in the while loop?
borono wrote: I hope that...my question is clear.
Given that you did not show the exact code that is causing the problem, it's going to be hard to offer any real help.
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"There is no death, only a change of worlds." - Native American Proverb
|
|
|
|
|
Without seeing your real code, ie. without all the blah's, it's gonna be a little hard to find your problem. But one thing does stand out. Each time you loop, you are opening the file, then you close it after the loop. This is an uneven ratio of open/close. You should really open the file before the loop, do the wrinting inside the loop, close it after the loop.
|
|
|
|
|
I tried your suggestions, but they didn't seem to help --same results. No one has said this is impossible, so I am glad about that. And, my code is so long at this point, I thought to post it would be unbearable. However, if either one of you would like me to mail it to you, I would be more than willing to zip it right up and send it on over. Let me know on that.
I just don't understand why it would work in my exe but not in my dll? The format I showed you is the same for the exe and it works flawlessly, so I am baffeled.
Anyway, an access violation probably isn't writing to the file, it is trying to reference bad memory, right? But, when I remove the writing portion, it works fine. I bet it is this here:
fprintf(out, "%.2x", pkt_data[i-1]);
I defined pkt_data[i-1] as:
const u_char *pkt_data;
but in my exe I defined it as simply:
u_char *pkt_data;
...could that be the reason. Because, that is the only thing that changed during the transition. It kept complaining about not being able to make the conversion.
I hope that provides what you need. If you need more, let me know and also I can send my code via email to whoever wants to give it a shot. thanks in advance.
|
|
|
|
|
It sounds to me like you are trying to write an unitialised variable. When you define a variable as const, it must be initialised with something, and cannot be changed for the duration of the exe.
I have a feeling you are trying to write data to u_char somewhere and it isn't happening. Remove the const, and instead set the memory and zero it. When you come to use it later simply test it.
|
|
|
|
|
Hey, thanks for the reply. Here is the result of removing const, minus setting the memory and zeroing it, because I am not sure what that means or how to do that. I am still quite new. Hopefully, this provides a better description of the 0xc0000005 access violation error I am having and why.
ERROR: C:\test.cpp error C2664: 'pcap_next_ex' : cannot convert parameter 3 from 'unsigned char ** ' to 'const unsigned char ** '
Caused by: u_char *pkt_data
Prevents error: const u_char *pkt_data
Here is where it is intialised: while((res = pcap_next_ex( fp, &header, &pkt_data)) >= 0)
Here is where it fails: (5 times through)
if (i < 7) { //dst address (ETH)
fprintf(out, "%.2x", pkt_data[i-1]);
if (i > 0 && i < 6) { fprintf(out, ":"); } else { fprintf(out, "\neSrc="); }
I am sorry, but I do not know what you meant by: "...set the memory and zero it. When you come to use it later simply test it." Can I see an example?
If you need more info, let me know. Thanks in advance.
|
|
|
|
|
borono wrote: am sorry, but I do not know what you meant by: "...set the memory and zero it. When you come to use it later simply test it." Can I see an example?
sure:
unsgined char *foo;
foo = new unsigned char [100];
ZeroMemory(foo,sizeof foo);
int size = strlen((char *)foo);
strcpy((char *)foo,"Some random string");
if (!foo)
MessageBox(0,"foo is still empty",0,0);
delete foo;
As for your code, have you checked the size of pkt_data? You are using it as an array, but are you sure it is correctly being initialised? It's hard to see from your code since you do it in a while loop and there is no specified number of loops.
You later use if(i<7) which may be reading past the end of your array. Watch the values of i at this point. I would also put a check for the size there: if ((i<7)&&(i<strlen(pkt_data)).
If you have further problems, and if you are using VC6, I can take a look at your project.
|
|
|
|
|
waldermort wrote: Watch the values of i at this point.
Especially when i is equal to 0. Then, referencing an array with -1 would be very suspicious.
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"There is no death, only a change of worlds." - Native American Proverb
|
|
|
|
|
borono wrote: could that be the reason.
If you suspect it is, then try:
fprintf(out, "%.2x", 123);
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"There is no death, only a change of worlds." - Native American Proverb
|
|
|
|
|
@DavidCrow
Good idea and I tried that just now and it still failed after five times through. I have yet to try waldermort's suggestion, so let me try that here in a few hours, after I get off work and I will let you know if that fixed it. I am sure it is something very simple. I write in assembler too and when I first started I kept forgetting to initialise the DS in my code, went through everything over and over, got real frustrating but showed my code to a friend, he saw it and that was that. --something so simple it hurts. I bet that is what this is too.
Im off in three hours, talk to you again then. thanks guys.
|
|
|
|
|
borono wrote: Good idea and I tried that just now and it still failed...
Which indicates the problem (probably) has nothing to do with pkt_data .
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"There is no death, only a change of worlds." - Native American Proverb
|
|
|
|