RAM Disk
in [MFC]
|
Prev: SetGet control input
Next: Copy constructor
From: vvf on 11 May 2010 06:56 Hi Goran, Thanks for all your valuable input! > I don't understand why you are having problems > with img and a, it's rather straightforward, Indeed, the only problem is when you have a file of the form "x.y.htm" ; x.y.htm does not work while x.htm works. vvf __________ Information from ESET Smart Security, version of virus signature database 5104 (20100511) __________ The message was checked by ESET Smart Security. http://www.eset.com
From: Goran on 11 May 2010 07:18 On May 11, 12:56 pm, "vvf" <v...(a)vvf.com> wrote: > Hi Goran, > > Thanks for all your valuable input! > > > I don't understand why you are having problems > > with img and a, it's rather straightforward, > > Indeed, the only problem is when you have a file of the form "x.y.htm" ; > x.y.htm does not work while x.htm works. <a href="otherPage.x.htm">other.x</a> <a href="otherPage.htm">other</a> and otherPage.htm HTML "otherPage.htm" otherPage.x.htm HTML "otherPage.x.htm" work here. I would guess you made an error somewhere. Here's the thing: normally, it should be 100% irrelevant, to the browser, what is happening with names and stuff, as long as the URL is correct. When putting stuff into resources, you have fixed "base" url, and that's res://path-to-exe.exe/. If you use relative URLs, you can simply specify the name of the resource in your src or href attribute, and you're done. All your URLs, sen as absolute are like so: res://path-to-exe.exe/page1.html res://path-to-exe.exe/page2.html res://path-to-exe.exe/page3.html .... res://path-to-exe.exe/img1.png res://path-to-exe.exe/img2.png and you reference them by specifying their name (src="img1.png", href="page2.html"). It would be hugely amazing that this simple thing (use of relative URLs in a browser) does not work in any scenario. Perhaps your interaction with Visual Studio resource editor broke something? Perhaps you should check your *.rc in a text editor? Or put stuff in *.rc2, it's there for simple manual editing? (BTW, while talking to you, I've been modifying my *.rc by hand exactly because I don't like fighting with VS editor, who stubbornly wants numeric resource IDs.) Goran.
From: vvf on 11 May 2010 10:20 Goran, /../ > <a href="otherPage.x.htm">other.x</a> > and > otherPage.x.htm HTML "otherPage.x.htm" > work here. Correct. That works for me as well. It seems that it doesn't work if you have a NUMBER before the first period. :) For example, while otherPage.x.htm HTML "otherPage.x.htm" works, 16.x.htm HTML "otherPage.x.htm" does not. However, 16x.htm HTML "otherPage.x.htm" works while 16.htm HTML "otherPage.x.htm" does not work. Therefore, I guess it wasn't really that it didn't work w/ more than one period, it was really the fact that you can't start with <number><period>. vvf __________ Information from ESET Smart Security, version of virus signature database 5105 (20100511) __________ The message was checked by ESET Smart Security. http://www.eset.com
From: vvf on 11 May 2010 10:30 I just posted a reply and my message expired "instantly". Therefore, I'll post again: What I basically discovered is that if you have something of the form: <number><period>*.htm, it will not work. Example: 16.htm HTML "page.htm" 16.x.htm HTML "page.htm" will not work. However, 16x.y.htm HTML "page.htm" 16x.htm HTML "page.htm" will work. Therefore, I just happened to be in a "special case" situation, didn't really have anything to do w/ the number of periods. My definition was of the form: 16.content.htm HTML "16.content.htm". vvf "Goran" <goran.pusic(a)gmail.com> wrote in message news:abf69fdd-d6fa-4908-afb4-18245e552b09(a)t17g2000yqg.googlegroups.com... On May 11, 12:56 pm, "vvf" <v...(a)vvf.com> wrote: > Hi Goran, > > Thanks for all your valuable input! > > > I don't understand why you are having problems > > with img and a, it's rather straightforward, > > Indeed, the only problem is when you have a file of the form "x.y.htm" ; > x.y.htm does not work while x.htm works. <a href="otherPage.x.htm">other.x</a> <a href="otherPage.htm">other</a> and otherPage.htm HTML "otherPage.htm" otherPage.x.htm HTML "otherPage.x.htm" work here. I would guess you made an error somewhere. Here's the thing: normally, it should be 100% irrelevant, to the browser, what is happening with names and stuff, as long as the URL is correct. When putting stuff into resources, you have fixed "base" url, and that's res://path-to-exe.exe/. If you use relative URLs, you can simply specify the name of the resource in your src or href attribute, and you're done. All your URLs, sen as absolute are like so: res://path-to-exe.exe/page1.html res://path-to-exe.exe/page2.html res://path-to-exe.exe/page3.html .... res://path-to-exe.exe/img1.png res://path-to-exe.exe/img2.png and you reference them by specifying their name (src="img1.png", href="page2.html"). It would be hugely amazing that this simple thing (use of relative URLs in a browser) does not work in any scenario. Perhaps your interaction with Visual Studio resource editor broke something? Perhaps you should check your *.rc in a text editor? Or put stuff in *.rc2, it's there for simple manual editing? (BTW, while talking to you, I've been modifying my *.rc by hand exactly because I don't like fighting with VS editor, who stubbornly wants numeric resource IDs.) Goran. __________ Information from ESET Smart Security, version of virus signature database 5105 (20100511) __________ The message was checked by ESET Smart Security. http://www.eset.com __________ Information from ESET Smart Security, version of virus signature database 5105 (20100511) __________ The message was checked by ESET Smart Security. http://www.eset.com
From: Joseph M. Newcomer on 11 May 2010 11:18
A real RAM disk ais a device, and therefore cannot be limited to a single application. Windows security is based on user tokens, and an application has a user token for the logged-in user. joe On Tue, 11 May 2010 11:51:13 +0300, "vvf" <vvf(a)vvf.com> wrote: >Hi Joe, > >Thanks for your message. > >> **** >> What does any of this have to do with the concept of a RAM disk? Nothing >> whatsoever, as >> far as I can tell. >> **** > >Well, I naively thought that I could just start with all the files >compressed and then uncompress them to a "RAM disk" that would only be >visible to my application but I thought about it more and that just doesn't >make any sense... > >vvf > > > >__________ Information from ESET Smart Security, version of virus signature database 5103 (20100510) __________ > >The message was checked by ESET Smart Security. > >http://www.eset.com > > > Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm |