reyn@trsvax.UUCP (06/29/90)
For those who have already developed applications for Windows 3.0 ... prefereably for those who have also developed a DLL ... Which debugger do you find the most useful for development ( CodeView, Turbo Debugger, Periscope, Symdeb, etc. ) I have no experience with Windows, but in the DeskMate environment most debuggers just didn't cut it when developing DLLs ( DeskMate calls them resources ). When debugging the code in the DLL it is necessary to load ( or switch to ) a seperate symbol table from the one which you need to debug the app itself. CodeView can't ( I should say couldn't ) do this, Periscope and Symdeb can. I am also currious about the availability of the API's for various MicroSoft DLLs. For instance, WinWord comes with a nifty spell checker and thesaurus, both of which appear to be DLLs. I know it would be improper to distribute these DLLs, but it should be reasonable for someone who has bought WinWord to run an application which uses WinWord's DLLs. This goes for any DLL by the way, not just MicroSoft's. Forgive me if these topics are covered in the Windows 3.0 SDK, as of yet they are not available in my area. Hopefully they'll be here soon. John Reynolds Standard Disclaimers Apply
fraley@hprnd.HP.COM (Andy Fraley) (07/03/90)
/ hprnd:comp.windows.ms / reyn@trsvax.UUCP / 9:00 am Jun 29, 1990 / For those who have already developed applications for Windows 3.0 ... prefereably for those who have also developed a DLL ... > Which debugger do you find the most useful for development ( CodeView, > Turbo Debugger, Periscope, Symdeb, etc. ) I find CodeView adequate for most things. > I have no experience with Windows, but in the DeskMate environment most > debuggers just didn't cut it when developing DLLs ( DeskMate calls them > resources ). When debugging the code in the DLL it is necessary to load ( > or switch to ) a seperate symbol table from the one which you need to debug > the app itself. CodeView can't ( I should say couldn't ) do this, > Periscope and Symdeb can. I use CodeView (CVW) to debug my DLLs in protected mode, SYMDEB to debug in real mode. For CodeView, just compile the DLL modules with -Zi and link with /CO. Run CVW in Windows 3.0 and specify the DLL's parent application as the application to run. If there is no debug info compiled into the parent, you'll get a warning message which you can ignore. CodeView then asks you to "Name an other DLL or executable with debug info." Just type in the name of the DLL with the debug info. For more information, see the Windows 3.0 SDK manuals. -Andy Fraley HP Roseville Networks Division
tonyb@olivej.olivetti.com (Anthony M. Brich) (07/06/90)
This message is not in response to whatever message may be
indicated. It is a "fresh" posting. I am posting "in
response" because our news does not allow posting *except* in
response to other messages.
Word For Windows warning!
Direct character formatting is subordinate to paragraph
style character formatting.
I knew this when I started using WinWord, but now I'm really
LEARNING the significance of this subtle "design flaw" (if you
will permit the use of such dramatic language), at least for those
of us who rely on direct character formatting in our
documents.
I am writing a technical manual. I use Helvetica LowerCase
10-point bold small caps to indicate keys (like ENTER and DEL)
which the user must press. I have defined glossary items for
each key, which includes character formatting. But when I
insert the glossary item, the character style for the
PARAgraph in which I am inserting the text redefines SOME but
not ALL of the character formatting attributes of the string.
For instance, if I insert the ENTER glossary item in a
paragraph which has character style defined as Helvetica No-Bold 20
point Underlined (it's a chapter heading), ENTER comes out
Helvetica, No-Bold 20 point Small-Caps(!). So, ENTER retained
the small-caps style, but everything else was redefined by the
paragraph style. John at Microsoft Support insists that this
is how Winword works with styles and formatting, that is, the
character formatting contained in the paragraph mark overrides
direct formatting of characters. I find this hard to believe,
but I spent a half hour this morning talking to him about it,
so there you are.
Also, if I direct format first, then apply a paragraph style
to paragraphs which contain direct formatted characters, the
direct formatting is cancelled.
John tried to talk me into a complicated workaround involving
tables in which cells are specially formatted to separate my
ENTERs from the paragraph surrounding them ... I blanched
when I thought of what he was telling me. Complicated tables
slow Winword down to a crawl, even in short documents. And,
it would be very difficult designing such tables in the first
place! The table feature may be a powerful object-oriented
joy in terms of ease of manipulating tables, but it comes at a
significant cost in performance.
The implications are sobering: I have to carefully PLAN
mydocuments, before I start writing them! What a thought!
I'm of the school: "the best of plans .... get changed".
It's a pragmatic viewpoint, maybe a little messy, but it seems
to hold true. And the whole point of a good word processor is
to give you power over your document, not to give the power TO
your document!
Now, in Word 5.0 ....
You have Character styles, as well as Paragraph and Division
styles, so you have a lot of discretion in defining a
stylesheet. Also, character formatting is retained REGARDLESS
of the character format of a specific paragraph style, unless
you manually turn OFF direct formatting (Alt-SpaceBar, or
Alt-x-SpaceBar, if you have a stylesheet attached to a
document).
So for those of you considering a move to Winword from
character-based products (esp. Word 5.0), best to assess just
what it is that you need from stylesheets. Winword's just
aren't that powerful.
(For the most part, I adhere to the principles of "the fewer
fonts used, the more attractive the document", and "documents
with simple stylesheets are more readable than documents with
complicated stylesheets, or than documents without stylesheets
at all". However, judicious use of standard direct character
formatting can help make computer application user
guides more readable by helping the reader distinguish
between text to be entered and special keys to be
pressed. I welcome comment on this point.)
Tony Brich
P.S. By the way, I think Microsoft support is getting burned
out. Twice in the last couple weeks, I have received less
than helpful responses from support techs there, one of whom
has been great in times past --- friendly, patient,
helpful. I think the strain of the last few weeks is telling:
tempers are shorter, the techs seem less tolerant of friendly
criticism and inquiry, especially with Winword. But hey,
Microsoft sold it as a GUI upgrade to Word 5.0. So I think
we're justified in complaining about the missing functionality
of the product, even as we praise its extraordinary power,
i.e. macros, customizable menu structre, fair WYSIWYG
(impressive, given the diversity of displays and printers out
there. Apple's achievement pales when you consider they
controlled all the components!). Etc. Anyway, be forewarned.
You'll be on hold forever, and then you may get a crabby tech!
Sheesh. And you'll pay the long distance charges for the
privilege!