PrinterCanvas class >>choose Problem
acg
I have written an application which uses PrinterCanvas class >> choose,
to allow the user access to the common printer dialog box. My problem
is that everything works well from my application in the development
enviroment, and workspace. But after making an .exe via Lagoon, using a
bare-bones runtime session manager, and then launching the app, I get
an error that 'choose' is not available, so I can't anything out.
Any thoughts ?
acg
Chris Uppal
In D6 PrinterCanvas class>>choose is a loose method. It is in package 'Dolphin
Common Dialogs' (a change from D5 where it is not loose). So if your code
doesn't include that package amongst its pre-requisites (perhaps indirectly),
the package will be removed in a very early phase of image stripping -- and the
method will vanish.
If that is the problem then you can add an explicit dependency by adding
'Dolphin Common Dialogs' to your package's #manualPrerequisites (access to
which is hidden inside the package's "properties" in the PB).
I believe that D6 is supposed to have some built-in way to check for such
situations before they occur -- but I can't find it offhand.
If that's not the problem then I have no idea what's going wrong...
-- chris
acg
Chris Uppal wrote:
... In D6 PrinterCanvas class>>choose is a loose method.
Hi Chris,
Hmm good thought. I'll try it.
Finally a praise for Dolphin Smalltalk and this forums help on all
counts. I finished my first ST Dolphin project. I confessed I've played
with Dolphin many times, but could not get an intuitive feel for MVP.
But after some interactive workspace experimentation and hints from
helpful people like you, I accomplished an 'incredible' conversion.
I had written app in ST/V about 1 1/2 years ago as my first ST project
which was primarily built with its GUI builder, WindowBuilder. I used
the app daily in my business. The app consisted of about six separate
windows which had to keep track of changes, and update info with each
keystroke. I think I took about 2+ months to put together. These
screens are widget intensive, much like a data entry forms with
checking and cross-checking, summing and cross-referencing, lookup
table stuff, somewhat like multiple linked spreadsheets would have to
be.
I used about 100+ TextPresenter.Static text, 60+ChoicePresenters.Combo
Box, 10 ListPresenter.Default view, 14 NumberPresenter.Slide view, 6
BooleanPresenter.Check boxes, 8 BooleanPresenter.Radio buttons 10
PushButton.Push buttons and a fiew TextPresenter.Devault view. and 2
CardContainers and a few Presenter.Container view and one subclassed
Shell, and one Date presenter. Some of the widgets were used in odd
ways. Some ListPresenters were used as a 'scoreboard' to verbally
indicate pregress, as mild..moderate..severe. Sliders were use more as
a tri-state (negative-null-positive)because Dolphins tristate button
was too hard to visually differentiate 3 separate states.
Some presenter states had to act as indicator when other values
changed, and be program resettable.
I planned 6 weeks to convert from ST/V to Dolphin, realizing that much
of the non-GUI code was re-usable.---Here's the killer, remember this
was my First real Dolphin project, and second 'smalltalk'
project.....The conversion took only 2 days, mainly because I could
build and test in a workspace, and used SUnit Testing for non-gui stuff
as needed.
The final app works and looks better than my ST/V version. The
coup-de-grace was when one of the 'slices' for a card container needed
to be customized for another colleagues work, with a similar multiple
of 20+ ChoicePresenter and default choices for each.
I thought that It might take about 1/2 day to get it done.
But after building the subpresenter and testing its functionality in a
workspace as it was being built (3+ hours), I was able to use
inheritance and subclass my mainShell and drag in the new subpresenter.
It only to ONE LINE in #createComponents to get the funtionality
complete.... total time 5 minute (vs estimated 1/2 day).
So I actually finished BOTH projects in the 2 days. I can recall
trivial class projects taking a few hours in C/C++
Thanks again for everyone's willingness to help
ACG
Chris Uppal
> I used about 100+ TextPresenter.Static text, 60+ChoicePresenters.Combo
> Box, 10 ListPresenter.Default view, 14 NumberPresenter.Slide view, 6
> BooleanPresenter.Check boxes, 8 BooleanPresenter.Radio buttons 10
> PushButton.Push buttons and a fiew TextPresenter.Devault view. and 2
> CardContainers and a few Presenter.Container view and [...]
... and a partridge in a pear tree ?
;-)
> So I actually finished BOTH projects in the 2 days.
That's pretty damn impressive!
-- chris
acg
Chris Uppal wrote:
>> That's pretty damn impressive!
>
Yours were some of messages that help me. BTW a D6.01 .exe deployment
ran fine on XP. But not on a Win98, because of a missing msvcr71.dll.
Any thought on making run on Win98 ?
I did a executable from D5.1.4 which ran fine on Win98, but on XP, some
of the static text box and slider background colors would not stay
matched up from re-deployment even without alteration of ST code. The
slider background color would self correct when the mouse pointer
passed of over the widget. But the static text stayed off color.
Any thought ?
Thanks again
ACG
Chris Uppal
> Thanks Chris.
> Yours were some of messages that help me.
Glad to help ;-)
> BTW a D6.01 .exe deployment
> ran fine on XP. But not on a Win98, because of a missing msvcr71.dll.
> Any thought on making run on Win98 ?
I wouldn't hope for too much. It /might/ be possible to make it work, but (as
far as I know) OA don't run Dolphin at all on W98 anymore, let alone support
deployment to that platform. Still, I believe that msvcr71.dll is a
distributable Windows component so you should be legally OK if you include it
in your deployment (check MSDN for how to do that legally) but, I don't think
MS support W98 anymore either, so you can guess for yourself what the chances
of it working properly are. /My/ guess is that you'd be forever chasing one
bug after another.
> I did a executable from D5.1.4 which ran fine on Win98, but on XP, some
> of the static text box and slider background colors would not stay
> matched up from re-deployment even without alteration of ST code. The
> slider background color would self correct when the mouse pointer
> passed of over the widget. But the static text stayed off color.
Do you mean that you see problems deploying from D5 and running on WinXP ?
There haven't been a lot of complaints from people using that combination
(after all, D5 has been running on XP since it came out). You may be
experiencing a problem caused by a missing manifest file, but that seems a long
shot given the symptoms you describe.
I can't think of anything sensible to suggest[*], so I suspect that unless you
can create a reproducible example, you may be stuck with deploying from D5 or
Win98, and D6 for Win2K/WinXP. Not a nice situation, I agree.
-- chris
[*] I don't mean to suggest that someone else won't have sensible suggestions.
acg
Chris Uppal wrote:
Hi Chris,
>... Do you mean that you see problems deploying from D5 and running on WinXP ?
Yes, properly compiled, and running on D5 .exe version had background
colorshift
on WinXP. Forcing re-deployment without editing smalltalk code or
resource settings
caused another random widget background to unmatch the container
background. Sometimes one and sometimes two widgets, usually static
text and slider background.
But same code deployed under D6.01 works / looks fine under XP. Looks
like I'll have to stay with D6.01 or better.
>... so I suspect that .... you may be stuck with deploying from D5 or
> Win98, and D6 for Win2K/WinXP. Not a nice situation, I agree.
I think your right.
Another problem I found was the that running .exe from D5.1.4
deployment on Win98 would no completely unload from processes on exit,
but the same .exe on WinXP would unload.
By the way your suggestion for using 'manualPrerequisites' for
PrinterCanvas got my stuff printing properly, so thanks again
ACG
acg
After a little searching and thought, I found I could avoid the random
color problem by setting all presenters' backColor to 'Color face3d'
instead of 'nil' or 192/192/192 (grey).
But to affect the sliders, I had to go modify Silder class
>>publishedAspectsOfInstances by commenting out 'removeKey: #backColor; '. This allowed View Composer access to slider's backColor. But to affect the re-colored slider, I had to toggle 'isTransparent' to true then false again.
But, Wow, I don't recall being able to modify a GUI properties sheet
like that in another programmer environment
Thanks
ACG