Home > Archive > Cobol > September 2006 > Use of the Registry was Re: Conext Menus
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Use of the Registry was Re: Conext Menus
|
|
| Clark F Morris 2006-09-07, 9:55 pm |
| I am keeping the posting below for background for this posting. The
use of the registry in Windows as the repository for all sorts of
application information leads to a more vulnerable system. OS2 has
the same vulnerability (OS2 still exists but only barely). I don't
know whether Unix and Linux have a registry equivalent. What we have
is a single entity crucial to the system manipulated by applications
which come and go. The uninstall process may or may not clean up the
registry entries. There may or may not be utilities adequate for safe
updating of the registry. I have tried a few of them, all of which
required paying close attention and understanding a fair amount about
the system. While the parameter library entries used by z/OS can be
cryptic and confusing, they are in plain text and those libraries used
by the system are normally only affected by the system related entries
or such things as databases or systems utilities and enhancements.
Normal applications normally don't touch them and all information
controlling the applications is normally kept in libraries/files
unique to the application or application suite. In short I find that
the use of the registry by applications is a design with opportunities
for foulup and malice.
On Fri, 18 Aug 2006 16:01:17 +1200, "Pete Dashwood"
<dashwood@enternet.co.nz> wrote:
>
>"James J. Gavan" <jgavandeletethis@shaw.ca> wrote in message
>news:8w7Fg.415894$iF6.66077@pd7tw2no...
>
>A point that may have been missed here is that context menus are a standard
>part of the Windows environment. You can create them easily by modifying a
>few Registry entries. No code is required, although most people would
>probably install them in the same script that starts the app. (if it starts
>with a script...).
>
>For windows applications like IE and Word, you can certainly modify or add
>your own context menus to the standard context menus, using Registry mods,
>and you can probably do the same with any given window (I haven't tried
>it...)
>
>IF I was going to write a component which did context menus (and I'm not
>:-)) I would simply call the API to modify the appropriate Registry entries
>for the application window. There would be a Method in the component that
>let the User define what was wanted....the tree required and the events that
>trigger that tree, bearing in mind that the tree selections depend on the
>context in which they are activated. Once the component had the
>requirements, it would make the necessary Registry amendments. It is really
>pretty simple.
>
>Pete.
>
>
| |
| Pete Dashwood 2006-09-07, 9:55 pm |
|
"Clark F Morris" <cfmpublic@ns.sympatico.ca> wrote in message
news:utf1g21ger22q0c4n0cq8nghqrpdqrtapr@
4ax.com...
>I am keeping the posting below for background for this posting. The
> use of the registry in Windows as the repository for all sorts of
> application information leads to a more vulnerable system. OS2 has
> the same vulnerability (OS2 still exists but only barely). I don't
> know whether Unix and Linux have a registry equivalent. What we have
> is a single entity crucial to the system manipulated by applications
> which come and go. The uninstall process may or may not clean up the
> registry entries. There may or may not be utilities adequate for safe
> updating of the registry. I have tried a few of them, all of which
> required paying close attention and understanding a fair amount about
> the system. While the parameter library entries used by z/OS can be
> cryptic and confusing, they are in plain text and those libraries used
> by the system are normally only affected by the system related entries
> or such things as databases or systems utilities and enhancements.
> Normal applications normally don't touch them and all information
> controlling the applications is normally kept in libraries/files
> unique to the application or application suite. In short I find that
> the use of the registry by applications is a design with opportunities
> for foulup and malice.
>
I don't feel as strongly as you do, although I would not disagree with the
points you raised. The Registry can certainly be misused by applications.
But it can be a powerful tool for supporting applications also.
What is important here is that context menus were DESIGNED into the
OPERATING SYSTEM ENVIRONMENT. There is absolutely no need for application
programs to build them, any more than it is necessary for application
programs to monitor and control task execution and switching.
You simply decide what context menus you want for a given application, then
register those options for that application. It is simple and useful. The
operating Environment has been desiged to be flexible enough to allow you to
do this. It just happens that this flexibility is imlemented through the
Registry.
Pete.
[color=darkred]
> On Fri, 18 Aug 2006 16:01:17 +1200, "Pete Dashwood"
> <dashwood@enternet.co.nz> wrote:
>
| |
| James J. Gavan 2006-09-08, 3:55 am |
| Pete Dashwood wrote:[color=darkred]
> "Clark F Morris" <cfmpublic@ns.sympatico.ca> wrote in message
> news:utf1g21ger22q0c4n0cq8nghqrpdqrtapr@
4ax.com...
>
>
>
> I don't feel as strongly as you do, although I would not disagree with the
> points you raised. The Registry can certainly be misused by applications.
> But it can be a powerful tool for supporting applications also.
>
> What is important here is that context menus were DESIGNED into the
> OPERATING SYSTEM ENVIRONMENT. There is absolutely no need for application
> programs to build them, any more than it is necessary for application
> programs to monitor and control task execution and switching.
>
> You simply decide what context menus you want for a given application, then
> register those options for that application. It is simple and useful. The
> operating Environment has been desiged to be flexible enough to allow you to
> do this. It just happens that this flexibility is imlemented through the
> Registry.
>
> Pete.
>
>
>
Well, as Clark moved this to a new topic, let's cover two things -
Registry and Context-Menus.
REGISTRY -
I was sympathetic to Jerry's cautionary note. A short while back, from
the desktop I looked at the MS Help, to glean something on what Registry
was about. Not exactly MS wording but it read like, "Don't mess with
Registry entries unless you *really* know what you are doing......".
That was enough to put me off. There again Registry entries are deeply
hidden so that you can't immediately easily jump into them from the
Windows Explorer. I would feel even more inclined to ignore Registry
based on Clark's comments. Now I can't quote you chapter and verse but
in the M/F Forum, the M/F people have (I believe) suggested Registry as
a solution to specific problems. (I'll get back to your Registry usage
after running though 'Menus'.
MENUS/POP-UPS/CONTEXT-MENUS.
I didn't know what 'Context-Menu' meant but was aware of Pop-Up Menus -
one of which I used. So I did reading of various sources, and eventually
established that 'Pop-Up' and 'Context-Menu' are different names for the
same animal. There was no reference to 'Context-Menu' when referring to
GUI classes or the general help. (However general Help did mention
Context-Help - where you have that question-mark top-right in a dialog
and drag and drop it to a particular control, where a short message
pops-up describing the control). As a final thought - I checked out the
specific help file for Dialog System - went to the glossary
'Context-Menus - see Pop-Up Menu'.
I was going to write to the M/F Forum and ask about the webbing aspect -
I'll come to that in a minute. But as the original enquirer appears to
have lost interest, thought to myself, "Why should I bother to pursue
it. I wont be using it".
It's a guess, but when Windows started up very likely the control was
called a Pop-Up Menu, but as the emphasis changed to webbing, MS came up
with the fancy name 'Context-Menu'.
So Pop-Ups/Context Menus are no big deal in any GUI tool. The M/F GUI
structure for menus is :-
Base
Dependent
GUI Base
MenuItem
SubMenu ( is class "menu" - inherits from MenuItem )
MenuBar (inherits from Sub-Menu)
PopUp-Menu (inherits from SubMenu) = Context Menu
Using Oliver's example, passing the common routine a set of menu
literals - If you want to produce :-
1) a Main Menu - invoke SubMenu "new" returning myMainMenu
The horizontal Menubar shows 'File' and the drop-down is the remaining
entries; of course there can be additional Menubar items and further
sub-menu options. A Main Menu stays displayed but disabled as you select
sub-items from the choices. (Can of course invoke myMainMenu "hide"
should you wish to do so)
2) Pop-Up only displayed as a result of a right click. So invoke
PopupMenu "new" returning myPopUp. I haven't experimented - but I'm
willing to bet that if you use the same set of literals provided by
Oliver, with a couple of additions, say 'Print' and 'Help' you will
likely get a VERTICAL :-
File
Print
Help
and the remainder of the Pop-Up will only appear as a result of
selecting 'File' :-
[color=darkred]
Really the only subtle difference between the two is which class is used
to create the instance. For Pop-us they are only displayed as a result
of a right-click. By convention, (and I haven't found out why), as you
right-click the X and Y co-ordinates of the mouse click are used to
position your Pop-Up - works on any of the traditional Web browsers.
So for a COBOL dialog system, passing 'Main' or 'Pop-Up' as the current
property will formulate how menus display.
WEBBING :
Now here's the tricky bit. I haven't done any webbing but took a quick
look at the M/F Forms module to produce a web page (HTML). Doesn't look
like you can include any sort of menu in your web page.
What's involved - you might find the following of interest from Microsoft :-
Asp.Net - http://msdn.microsoft.com/msdnmag/i...02/CuttingEdge/
Note the text of this document specifically makes the point that you
have to override the existing Context-Menu method :-
"....In Internet Explorer 5.0, and newer versions, it's the
OnContextMenu event. In Netscape 6.0 and newer versions you need to use
OnMouseUp. (You can also make OnMouseUp work for Internet Explorer 5.0+
browsers but this requires a little more coding.)....."
Just to complicate the situation Opera DOESN'T acknowledge a right-click
for a Pop-Up - you have to use some other key combination !
What I'm not clear about, without getting involved, is (a) Do you
include the override method as part of your Web Page, or (b) Do you have
to send the override message to the specific browser.
Suppose you have clients Tom, Dick, Harry and Annabelle; they each use
respectively IE, Netscape, Firefox and Opera. Just to be awkward
Annabelle alternates between IE and Opera. Now multiply your user base
by 50. How the hell do you handle that - part of your application
installation process - and what about Annabelle ?
What also seemed a possibility to me about using a Pop-Up with a browser
was that your menu could contain a couple of countries with reference to
pictures of different towns :-
England :
Bath, London, Portsmouth
Germany :
Berlin, Cologne, Dusseldorf
(Above could be a requirement for a Travel Agency with vacation sites).
Having made a menu selection, how can the appropriate URL be put into
the top of the Browser. (Briefly I'm assuming along with the city names
the literals to create the menus could also hold appropriate URLs; as
the menus are created use two OrderedCollection the first for the
displayable Pop-Up and the second to store the URLs - their index
position being the same as the menu choice number ???? )
It's easy if I include a URL in an MS Word document or even a message
here - highlight it and it takes you to that site through your browser.
How you pass the URL from a Pop-Up selection to the appropriate browser
beats me :-).
BACK to REGISTRY :
Seeing that the above document is the MS 'latest word' on how to tackle
Pop-Ups (Context-Menus) - exactly where would use of the Registry give
you an advantage over ASP.NET, not just a replacement Pop-Up but also
getting at the URLs for cities ?
Jimmy
| |
| Michael Wojcik 2006-09-08, 7:55 am |
|
In article <utf1g21ger22q0c4n0cq8nghqrpdqrtapr@4ax.com>, Clark F Morris <cfmpublic@ns.sympatico.ca> writes:
> I am keeping the posting below for background for this posting. The
> use of the registry in Windows as the repository for all sorts of
> application information leads to a more vulnerable system.
True. It's a classic OS-design mistake.
The Windows Registry is what's sometimes called a "compound file";
in essence, it's a filesystem implemented in a file. (In the case
of "the" Registry, there are actually multiple files, which is even
worse, because you have multiple virtual filesystems that have to
be "mounted" at the proper points to create the single hierarchical
view.)
While compound files are useful for some applications (zip archives,
for example), they require implementing most of a filesystem, and
have all of the problems of a filesystem - doubled, because there's
the filesystem that actually hosts the compound file. Look at the
Registry: it has hierarchical relationships and paths and ACLs and
content types, all the information that NTFS *already provides*.
If each Registry entry were a small file under a well-known location,
MS could have saved all that duplicated effort.[1]
Worse, since the compound file isn't an actual filesystem, all the
normal file-processing tools and utilities won't work on it.
Instead you have this black box and a handful of tools which have
to be invented specifically for the compound file.
There are Windows utilities (such as U/Win, an AT&T Unix-on-Windows
product) which actually provide a filesystem view of the Registry,
so you can use file-based tools on it. Unfortunately, it's painfully
slow, as the Registry is poorly implemented.
Alas, Microsoft's love affair with compound files shows no sign of
ending. They also use them for the PDB debug-symbol file format,
for Outlook email archives[2], and so on.
> I don't know whether Unix and Linux have a registry equivalent.
Standard Unix (SUSv3) does not. OS configuration is almost entirely
kept in well-known human-readable formatted-text files, which is one
of the things that makes Unix so much easier to administer than
Windows, for the experienced user. (For one thing, you can search
through thousands of plain-text files in half the time it takes to
locate one Registry entry with a tool like regedit.) Most Unix
applications follow suit.
Some Unix flavors have experimented with non-text configuration.
IBM's AIX has a small built-in DBMS called the Object Data Manager
(ODM) which is used to hold some system configuration information.
AIX 3 (the first modern release, for the original RS/6000 line) used
it for some of the standard Unix system configuration stuff. That
was not popular with users, and with AIX 4 most of it was moved back
to plain-text files.
[1] Some people might object to this design on the grounds that the
filesystem's cluster size means significant space would be wasted
by all those small files. That problem was solved years ago by
BSD's fragmenting filesystem feature, and there's no reason why MS,
with all of its resources, couldn't have implemented something
similar.
[2] Unfortunately, it seems this particular disease - storing email
messages in compound files - is pandemic on Windows. Even Mozilla
Thunderbird, which has now reached the stage of being almost
competent, continues to commit this blindingly stupid error. Look,
folks, BSD Mail got this right thirty years ago: PUT EACH MESSAGE
IN ITS OWN FILE. It's faster, it's safer, it's more robust, it's
easier to manage, it's easier for the MUA developer. There is *no*
good reason to use a compound file for email archives.
--
Michael Wojcik michael.wojcik@microfocus.com
Against all odds, over a noisy telephone line, tapped by the tax authorities
and the secret police, Alice will happily attempt, with someone she doesn't
trust, whom she can't hear clearly, and who is probably someone else, to
fiddle her tax return and to organise a coup d'etat, while at the same time
minimising the cost of the phone call. -- John Gordon
| |
| Oliver Wong 2006-09-08, 6:55 pm |
|
"James J. Gavan" <jgavandeletethis@shaw.ca> wrote in message
news:B66Mg.518043$iF6.396249@pd7tw2no...
>
> WEBBING :
>
> Now here's the tricky bit. I haven't done any webbing but took a quick
> look at the M/F Forms module to produce a web page (HTML). Doesn't look
> like you can include any sort of menu in your web page.
My recommendation: Don't try to mess with the user's right click options
for a web app. You'll run into all sorts of problems, including
cross-browser compatibility as you've noted. The bleeding edge for web apps
seems to be AJAX. Google Maps (http://maps.google.com/) uses AJAX, which
lets you click and drag to scroll the map around. Notice that right-clicking
is disabled completely there.
If you have to support right click context menus, your best bet would
probably to use a Java Applet or Macromedia Flash. This will embed a small
application in your webpage, which can do just about anything normal
applications can do (including intercepting mouse events).
- Oliver
| |
| James J. Gavan 2006-09-08, 9:55 pm |
| Oliver Wong wrote:
>
> "James J. Gavan" <jgavandeletethis@shaw.ca> wrote in message
> news:B66Mg.518043$iF6.396249@pd7tw2no...
>
>
>
> My recommendation: Don't try to mess with the user's right click
> options for a web app. You'll run into all sorts of problems, including
> cross-browser compatibility as you've noted. The bleeding edge for web
> apps seems to be AJAX. Google Maps (http://maps.google.com/) uses AJAX,
> which lets you click and drag to scroll the map around. Notice that
> right-clicking is disabled completely there.
>
> If you have to support right click context menus, your best bet would
> probably to use a Java Applet or Macromedia Flash. This will embed a
> small application in your webpage, which can do just about anything
> normal applications can do (including intercepting mouse events).
>
> - Oliver
As usual Oliver, good advice from you - thanks.
You've summed up my concerns in your first paragraph. Funnily enough,
possibly in c.l.c., I've recently seen another reference to AJAX.
(Perhaps in a message from Michael W. ?)
I've already got Google Maps downloaded but used your link to get to it.
So which Browser are you using - I'm using Mozilla Firefox and that does
STILL give me a a Firefox pop-up from a right mouse click !!! ( :-) ).
Back (greyed)
Forward (greyed)
Reload
Stop (greyed)
Bookmark this page
Save Page as...
etc......
I have two pet peeves with Windows, having made the transition from DOS
text mode to GUI-ing :-
1) Tab key to move between fields as opposed to the old DOS use of the
Enter Key. Some nut at the U. of Belliingham decided for us that the
Enter key would denote completion of data entry for a dialog.
2) Pop-Ups
Click away with a right-click and Winders will surprise you. I hate
that with a Pop-Up. I personally do not like to have to second guess an
application, nor do I think users should have to either. So although I
have produced two pop-ups (see below) - I cheat.
a) Firstly the particular class I'm extracting from below has two major
dialogs, relating to the one entity and both need to occupy the full
desktop to fit everything into an orderly fashion. Don't want the user
guessing - so I have a big fat Pushbutton at the bottom of the dialog :-
- when Item details are displayed the button shows "Show Readings"
- when Readings are being displayed the button shows "Show Item"
Tells the user what's available and they can happily switch between the
two dialogs.
b) As part of Item input I have to know the diameter of a pipe entered
as decimal inches 999.999. Depending upon whether diameter is expressed
as 'Outside' or an 'Inside' measurement, determines how the Critical
Thickness is calculated - i.e. the lowest, (or 'thinest'), thickness
this item can be before it comes up for replacement. OK this one I could
have done with a dropdown combo specifying either 'Outside' or 'Inside'.
I chose the pop-up approach - but - I don't use the right-click - only
displaying the Pop-up when the user focuses on the Diameter entry field,
as per following code :-
*>-------------------------------------------------------------
Method-id. "zPopupDiameter".
*>-------------------------------------------------------------
Local-Storage section.
01 ls-event pic x(4) comp-5.
01 ls-object object reference.
01 ls-Separator object reference.
Procedure Division.
invoke PopUpMenu "new"
using os-Dialog returning os-PopupDiameter
move p2ce-menuSelect to ls-event
invoke os-PopupDiameter "AddItemZ"
using z"&Outside diameter" returning ls-object
invoke ls-object "setEventto"
using ls-event, os-Caller, "PopUp-DiameterOutside "
invoke os-PopupDiameter "AddItemZ"
using z"&Inside diameter" returning ls-object
invoke ls-object "setEventto"
using ls-event, os-Caller, "PopUp-DiameterInside "
invoke os-PopupDiameter "create"
End Method "zPopupDiameter".
*>-------------------------------------------------------------
The two literals preceded by z"....", indicate that they are terminat4ed
with x'00'. As you can see - a simple Pop-Up is not mind boggling. I've
passed the object handle for Items/Readings Edit to the above class as
Os-Caller - so the callback, "setEventTo" returns the result to the
appropriate method in Items-Readings Edit.
c) Back to guessing what's available from a right-click, the Readings
dialog has a Pushbutton 'Other'. Huhh ! Sets you thinking - so you click
on it, (not right click) and get the info from the following method :-
*>-----------------------------------------------------
Method-id. "zPopupOther".
*>-----------------------------------------------------
Local-Storage section.
01 ls-event pic x(4) comp-5.
01 ls-object object reference.
01 ls-Separator object reference.
Procedure Division.
*> ViewRecords
*> Enter Item #
*> Separator
*> Delete Item and Readings Disable
*> Delete Readings only Disable
*> Zeroise columns Disable
*> Separator
*> First record
*> Last Record
The code for this Pop-up is similar to previous method giving the table
of choices shown.
It's the Business Logic class (Items/Readings Edit) which triggers the
display of the respective Pop-ups :-
invoke os-PopupDiameter "showAt"
using ws-diameter-x ws-diameter-y
invoke os-PopupOther "showAt" using ws-popup-X
ws-popup-y
Note I'm using my own co-ordinates rather that those generally
associated with a Context-Menu resulting from a mouse right-click, so
until I read up 'Context Menus' was not aware the Pop-Up gets positioned
on the right-click co-ordinates. (I don't see the necessity, but if I
wanted a Pop-up to move around the screen I could capture the
co-ordinates from the right mouse click and use those two ws-aaaa-x and
ws-aaa-y values above).
Nope, I wont be fiddling with Browser Pop-Ups in this or any other language.
While I'm at it, saw a screenshot in the M/F Forum - anybody seen the
Microsoft gimmick for transparent dialogs, associated with dotNet ? It's
like having a plain sheet of glass, with a blue border and say stick
some icons on sheet 1. Now do the same with sheets 2, 3, 4 etc., which
are behind it. Naturally some techno-freaks think it is just great. Pure
BS to me !
Jimmy
| |
| Pete Dashwood 2006-09-09, 6:55 pm |
| Some very quick responses below, Jimmy.
These posts are far too long and I simply don't have time to respond in
detail.
I don't see context menus as problematic so there is nothing of interest for
me here. I would not take the apporoach you have, so there's not much point
me responding to it. If what you are doing works for you, I have no further
comment.
"James J. Gavan" <jgavandeletethis@shaw.ca> wrote in message
news:B66Mg.518043$iF6.396249@pd7tw2no...
> Pete Dashwood wrote:
<snip>>>[color=darkred]
The above succinctly sums up what I think about this. I have nothing to add.
<snip>>[color=darkred]
> Well, as Clark moved this to a new topic, let's cover two things -
> Registry and Context-Menus.
>
> REGISTRY -
>
> I was sympathetic to Jerry's cautionary note. A short while back, from the
> desktop I looked at the MS Help, to glean something on what Registry was
> about. Not exactly MS wording but it read like, "Don't mess with Registry
> entries unless you *really* know what you are doing......". That was
> enough to put me off. There again Registry entries are deeply hidden so
> that you can't immediately easily jump into them from the Windows
> Explorer. I would feel even more inclined to ignore Registry based on
> Clark's comments. Now I can't quote you chapter and verse but in the M/F
> Forum, the M/F people have (I believe) suggested Registry as a solution to
> specific problems. (I'll get back to your Registry usage after running
> though 'Menus'.
I covered this in this thread already. There is a difference between MESSING
with the Registry and USING the Registry.
>
> MENUS/POP-UPS/CONTEXT-MENUS.
>
> I didn't know what 'Context-Menu' meant but was aware of Pop-Up Menus -
> one of which I used. So I did reading of various sources, and eventually
> established that 'Pop-Up' and 'Context-Menu' are different names for the
> same animal.
No they're not, exactly. This is a perfect example of ITSA, when it is
really ITSLIKE. Pop-ups do not require a given context and do not depend on
a given context. You can activate a pop-up at any time. A pop-up cannot be
implemented via the Registry, unless the pop-up is a pop-up menu.
I think you are saying pop-up when you mean 'pop-up MENU'
> There was no reference to 'Context-Menu' when referring to GUI classes or
> the general help. (However general Help did mention Context-Help - where
> you have that question-mark top-right in a dialog and drag and drop it to
> a particular control, where a short message pops-up describing the
> control). As a final thought - I checked out the specific help file for
> Dialog System - went to the glossary 'Context-Menus - see Pop-Up Menu'.
Maybe this is M/F usage.
>
> I was going to write to the M/F Forum and ask about the webbing aspect -
> I'll come to that in a minute. But as the original enquirer appears to
> have lost interest, thought to myself, "Why should I bother to pursue it.
> I wont be using it".
>
> It's a guess, but when Windows started up very likely the control was
> called a Pop-Up Menu, but as the emphasis changed to webbing, MS came up
> with the fancy name 'Context-Menu'.
No. It is a context menu because it is tied to a given context. Always has
been. Nothing fancy about it.
<snip>
> Really the only subtle difference between the two is which class is used
> to create the instance. For Pop-us they are only displayed as a result of
> a right-click. By convention, (and I haven't found out why), as you
> right-click the X and Y co-ordinates of the mouse click are used to
> position your Pop-Up - works on any of the traditional Web browsers.
>
Are you talking about Windows or the Web? One minute it was Windows, now Web
Browsers. Context menus in the Web environment can be implemented in many
different ways. Industrial strength Java apps would use AJAX, others may use
Java applets, or JavaScript or VBScript or server side code through
ASP/JSP...there are loads of possibilities.
> So for a COBOL dialog system, passing 'Main' or 'Pop-Up' as the current
> property will formulate how menus display.
That needs qualifying to be 'MICROFOCUS COBOL dialog system'.
>
> WEBBING :
>
> Now here's the tricky bit. I haven't done any webbing but took a quick
> look at the M/F Forms module to produce a web page (HTML). Doesn't look
> like you can include any sort of menu in your web page.
You certainly can. You can implement them in any of the ways mentioned
above.
>
> What's involved - you might find the following of interest from Microsoft
> :-
>
> Asp.Net - http://msdn.microsoft.com/msdnmag/i...02/CuttingEdge/
>
> Note the text of this document specifically makes the point that you have
> to override the existing Context-Menu method :-
>
> "....In Internet Explorer 5.0, and newer versions, it's the OnContextMenu
> event. In Netscape 6.0 and newer versions you need to use OnMouseUp. (You
> can also make OnMouseUp work for Internet Explorer 5.0+ browsers but this
> requires a little more coding.)....."
Those are standard events (NOT methods) for JavaScript, VBScript, and ASP.
Remember that ASP is (conventionally) SERVER side code. You could call out
to almost anything to build your menus...
>
> Just to complicate the situation Opera DOESN'T acknowledge a right-click
> for a Pop-Up - you have to use some other key combination !
Browser incompatibility is the bane of Web programming. W3C is addressing it
and more powerful development environments like MM Studio 8 allow you to
test across browsers and, in some circumstances will automatically tailor
your original script to make it compatible in different Browsers.
>
> What I'm not clear about, without getting involved, is (a) Do you include
> the override method as part of your Web Page, or (b) Do you have to send
> the override message to the specific browser.
What override method?
>
> Suppose you have clients Tom, Dick, Harry and Annabelle; they each use
> respectively IE, Netscape, Firefox and Opera. Just to be awkward Annabelle
> alternates between IE and Opera. Now multiply your user base by 50. How
> the hell do you handle that - part of your application installation
> process - and what about Annabelle ?
(We're all very worried about Annabelle... :-))
It is handled by scripts that detect which browser is reading the page and
present code it can recognise. Server side code (like ASP) may build the
page dynamically once it determines the Browser in use. (This is all good
fun and I've spent many happy hours doing it... :-) I'd rather have a tool
that does it for me and MacroMedia Studio 8 is on my Xmas list.) Actually,
given that Fujitsu don't appear to be interested in selling me NetCOBOL for
..NET (still no response), Xmas may come early... :-))
>
<snip>
> It's easy if I include a URL in an MS Word document or even a message
> here - highlight it and it takes you to that site through your browser.
> How you pass the URL from a Pop-Up selection to the appropriate browser
> beats me :-).
You place it within the appropriate HTML tags. It is simple. Just like any
other link.
>
> BACK to REGISTRY :
>
> Seeing that the above document is the MS 'latest word' on how to tackle
> Pop-Ups (Context-Menus) - exactly where would use of the Registry give you
> an advantage over ASP.NET, not just a replacement Pop-Up but also getting
> at the URLs for cities ?
Well you have taken their document out of context and you haven't understood
the methods and events they are referring to. I would NOT use the Registry
for context menus on the web. (I don't know of any way in which you could,
and 'impossibility' for me is enough to cause me to s another route...
:-))
On the desktop I use desktop tools (including the Registry); on the Web I
use web tools and languages. The two sometimes overlap because I may develop
a component that runs in either environment, but, for the most part, they
are separate developments.
('separate development'...? Didn't that use to be 'apartheid'?... I'll have
to investigate getting more political correctness into my stuff... :-))
Pete.
| |
| Oliver Wong 2006-09-11, 6:55 pm |
|
"James J. Gavan" <jgavandeletethis@shaw.ca> wrote in message
news:oSqMg.518791$Mn5.199347@pd7tw3no...
> Oliver Wong wrote:
>
> I've already got Google Maps downloaded but used your link to get to it.
> So which Browser are you using - I'm using Mozilla Firefox and that does
> STILL give me a a Firefox pop-up from a right mouse click !!! ( :-) ).
>
> Back (greyed)
> Forward (greyed)
> Reload
> Stop (greyed)
> Bookmark this page
> Save Page as...
> etc......
I'm using FireFox also, version 1.5.0.6.
On closer inspection though, I see you can right click outside of the
map (e.g. on the whitespace to the left of the map, or on the link lists on
the left) and have Firefox's menu appear. But right clicking on the map
itself doesn't trigger any menus.
[...]
> While I'm at it, saw a screenshot in the M/F Forum - anybody seen the
> Microsoft gimmick for transparent dialogs, associated with dotNet ? It's
> like having a plain sheet of glass, with a blue border and say stick some
> icons on sheet 1. Now do the same with sheets 2, 3, 4 etc., which are
> behind it. Naturally some techno-freaks think it is just great. Pure BS to
> me !
It looks like in MS Vista, the main contents of the window will have an
opaque background, but the border around it will be translucent:
http://www.johndavidhead.com/jhead/...tare-vista.jpg/$file/solitare-vista.jpg
With Linux and KDE, you can configure just about anything to be
transparent: http://gentoo-wiki.com/images/8/8d/...ransparency.png
Thankfully, you can also disable this and have everything opaque as well.
- Oliver
| |
|
| mwojcik@newsguy.com (Michael Wojcik) wrote:
>There is *no*
>good reason to use a compound file for email archives.
Incorrect. Or, if you don't consider it a "good" reason,
it's at minimum a practical reason. If you keep lots of Email
messages, that would be a lot of files. Windows handles really
large directories badly. It tends to get bogged down when
directories have "too many" entries. The compound file avoids
triggering this performance bug.
--
Ron
(user ron
in domain spamblocked.com)
| |
| Michael Wojcik 2006-09-12, 7:55 am |
|
In article <vu4bg25r697pm38efs3d8hg1un7feu0l1k@4ax.com>, Ron <ron@address.below> writes:
> mwojcik@newsguy.com (Michael Wojcik) wrote:
>
> Incorrect. Or, if you don't consider it a "good" reason,
> it's at minimum a practical reason. If you keep lots of Email
> messages, that would be a lot of files. Windows handles really
> large directories badly. It tends to get bogged down when
> directories have "too many" entries.
If only there were a way to prevent a directory from having too many
entries ... such as, say, subdirectories. NTFS is an extensible
hierarchy, you know.
(And, of course, the filesystem *can* be fixed. Using a grotesque
kluge to get around a deficiency in their own damn code does not
strike me as a particularly noble justification.)
> The compound file avoids triggering this performance bug.
First, most of the compound file implementations in Windows MUAs have
abysmal performance anyway. I've benchmarked searches in Outlook
"Personal Folders" versus grep'ing through exported folder contents -
grep is an order of magnitude faster.
Second, as I noted in my original posting, a compound file is a
virtual filesystem; there's no reason to believe that MUA authors
will do any better at creating a filesystem than the NTFS team, and
indeed evidence suggests they have not.
Third, as I noted above, there are other, better solutions to the
problem of poor OS filesystem directory performance.
Fourth, people who insist on keeping thousands of email messages in
one great unsorted heap likely have more pressing performance
problems caused by their reluctance to organize data; I don't see why
MUAs should be tuned for their needs.
Fifth, there are other penalties caused by compound files which far
outweigh the NTFS directory-performance issue: the difficulty of
extracting messages from compound files; the fragility of compound
files; the inability to use common tools with them, or to develop new
tools for them, because they're black boxes; the inability of
utilities such as virus scanners to deal with them as anything other
than monoliths.
This last is often particularly irksome. My personal email account
receives a lot of junk, including a great amount of attached malware.
That doesn't bother me; my spam filter catches it, and I don't let
my MUA process attachments. But if I let my virus scanner scan the
directories containing those compound files, it wants to "quarantine"
the compound file because of those embedded messages. And if it does
that, it takes the entire compound file, of course, which breaks the
MUA and prevents me from seeing any of my legitimate messages.
This is not a failure on the part of the scanner; it can't be expected
to understand the compound file format, which is some braindead black
box cooked up by some code-before-you-think jock who believes a home-
grown indexed file format is the solution to every data storage
problem.
So no, I don't think that's a good reason.
--
Michael Wojcik michael.wojcik@microfocus.com
Not the author (with K.Ravichandran and T.Rick Fletcher) of "Mode specific
chemistry of HS + N{_2}O(n,1,0) using stimulated Raman excitation".
|
|
|
|
|