Closed Bug 5564 Opened 21 years ago Closed 21 years ago

nslocale.dll: remove RegisterComponent() calls

Categories

(Core :: Internationalization, defect, P3)

All
Other
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: bobj, Assigned: tague)

References

Details

(Whiteboard: DEPEND - Intl)

Suresh Duddi wrote:
    1.Look at NS_SetupRegistry() and NS_SetupRegistry1() functions
    2.If your component lives under the components directory,
      remove the RegisterComponent() call from there

And then be happy you just improved the startup performance of
apprunner by saving an unneccessary dll load/unload combination.
Status: NEW → ASSIGNED
Checked in and tested the changes on Windows 4/27/98 - 2:00pm.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Target Milestone: M5
Status: RESOLVED → VERIFIED
I marked this as verified since the bug is a code issue, and there is nothing
for QA to really verify.
Messenger thread pane sort using this dll.
Using 4/29 Win32 build (after removing mozregisty.dat file), after I hit a tab
for the subject for sorting I got errors like this.
nsComponentManager: Load(nslocale.dll) FAILED with error: error 0
Is this related to this change? Looks like other components (e.g. converter) are
working fine.
I could be, I'll take a look at it.
Status: VERIFIED → REOPENED
Whiteboard: need status update
is this an M5 stopper?
I don't get any errors with 1999-05-03-08 build on US NT4.
I clicked on Subject, Sender and Date headers in the thread pane.
Naoki, Are you still crashing?
I used 1999-05-03-08 from ftp and still seeing the same message in the console
at first time hit a subject tab to sort. I have not seen crash for this, only
errors in the console as I mentioned in my previous comment.
Target Milestone: M5 → M6
We aren't getting a crash -- only console error messages on the first attempt.
Moving this to M6.
Resolution: FIXED → ---
Correction to my last comment.  On the first attempt to sort a header,
I do get the error messages in the console window.
Assignee: tague → dp
Status: REOPENED → NEW
I'm reassigning this to DP.  There is some problem with how nsComponentManager
is discovering the various components.  The reason the library load is failing,
is because the component manager is attempting to open "nslocale.dll", instead
of using the full path to the library (GetFullPath() is returing only the
library name and not the full path), so the call to PR_LoadLibrary fails.
Ok Here is what I did. I commented out all the calls to
RegisterComponent(NSLOCALE_DLL) from nsSetupRegistery.cpp

Invoked messenger. I get the folderpane and msglistpane empty. I clicked on the
headings Name, Unread, Subject, Sender, Date.

I see these output in my shell window. No msg about not being able to load
nslocale.dll without a path as it should be. Can someone help me reproduce the
bug:
OpenURL from XUL


nsMsgAppCore::SetWindow(): Getting the webShell of interest...
nsMsgAppCore::SetWindow(): Got the webShell browser.webwindow.
$573
$573
msgaccounts:/
msgaccounts:/
msgaccounts:/
----------------------------
-- Sort
-- Column: http://home.netscape.com/NC-rdf#Subject
-- Direction: ascending
----------------------------
$585

OpenURL from XUL


nsMsgAppCore::SetWindow(): Getting the webShell of interest...
nsMsgAppCore::SetWindow(): Got the webShell browser.webwindow.
----------------------------
-- Sort
-- Column: http://home.netscape.com/NC-rdf#Sender
-- Direction: descending
----------------------------
$585

OpenURL from XUL


nsMsgAppCore::SetWindow(): Getting the webShell of interest...
nsMsgAppCore::SetWindow(): Got the webShell browser.webwindow.
Assignee: dp → tague
move back to me
Status: NEW → RESOLVED
Closed: 21 years ago21 years ago
Resolution: --- → FIXED
Checked in a new fix for this with dp's help.

fix should be in 5/12/99 and later.
Whiteboard: need status update → DEPEND - Intl
QA Contact: 3851 → 4125
Tague, can you verify this fix? Thanks
Blocks: 7228
Status: RESOLVED → VERIFIED
marking verified since it is a code fix
You need to log in before you can comment on or make changes to this bug.