VA Smalltalk 8.5.2: unwanted content in text part

[arnd....@lvr.de]

Hi all,

after migrating our applications from VAST 7.5.2 to 8.5.2 we have come across a few problems:

1. In one of our software projects we use a text part that shows a help cursor if you move the mouse pointer into the part. We do that to signal that a selection list is available.

This still works in VAST 8.5.2 but different from VAST 7.5.2 these text parts are shown with special characters like vertical lines or squares and single letters in between as content when they should be empty. This effect also occurs in the composition editor.

If I click into the part these characters vanish and if I fill some real content in these text parts this is shown correctly.

How can we get rid of this unwanted content in our text parts? Does anybody have an idea why a text part shows content though the object is nil?

 

2. We use tool bars with buttons (AbtCwToolBarView and AbtCwToolButton) to choose the functions of the application. In VAST 8.5.2 these buttons only work in our application if you double-click them, while in VAST 7.5.2 a single click was enough. In the packaged application from VAST 8.5.2 you also only need a single click.

Does anybody here know what is necessary to change the behavior in the development environment?

 

We use Windows XP Professional SP 3.

 

Thanks!
Arnd

[Juergen Koepp]

 

Under Windows XP Professional SP3 and VAST 8.5.0  I get the same Doubleclick-Problem with AbtCwToolButtons!

 

Juergen

 

 

 

 

[jtu...@objektfabrik.de]

Juergen, Arnd,

try the following to get rid of the double click problem: check the option "use emulated Toolbar" in the "Options Menu" in the Transcript.

IIRC, Instantiations has added some code to auto-check this options in Windows Vista and Windows 7, but not in XP.

Once you've checked that, toolbars look better (flat) and work as expected. It persists image saves.

Let us know if that helps

Joachim

[jtu...@objektfabrik.de]

Arnd,

hav you tried setting the contents to an empty String, for example in an aboutToOpenWidget event handler. Not that this would be my suggestion in general, but I wonder if that would change the behavior you're seeing.

Joachim

[Thomas Koschate]

On Monday, February 4, 2013 3:20:54 PM UTC-5, jtu...@objektfabrik.de wrote:

try the following to get rid of the double click problem: check the option "use emulated Toolbar" in the "Options Menu" in the Transcript.

IIRC, Instantiations has added some code to auto-check this options in Windows Vista and Windows 7, but not in XP.

Actually, in my XP environment, we seem to be using the "emulated Toolbar" even though the option isn't checked.  Checking the option doesn't seem to make a difference in appearance or behavior.

Tom

[Juergen Koepp]

With Transcript Options >> "Use Emulated Toolbar" we use EtWindow>>#addEmulatedToolBarWindows instead of EtWindow>>#addOSToolbar for the Toolbars of EtWindow subclasses, i.e. for Development-Tools. The problem is not here in EtTools. For application programming we use AbtCwToolBarView + AbtCwToolButton , CwToolBar + CwToolButton, OSToolBar + OSToolItem. The last two have code changes between vast7 and vast85. Wenn EtTools toolbars are not emulated and flat they too use CwToolBar + OSToolBar, but they add an extra event handler for button down mouseclicks. So EtTools toolbars are working in native OS-mode too. Strange is only as in emulated mode too that the buttons fire not on mouse button up but on mouse button down immediatly. Why was this uncommon behaviour of buttons intoduced?

 

Under Vast 7 (XP SP3)

single button click release is calling these methods:

<21:05:15.171> OSWidget>>#postEvent: 3  "button up"

<21:05:15.174> OSToolItem>>wmCommandChild: 110

<21:05:15.176> CwBasicWidget>>#callButton1Up:

<21:05:15.178> CwToolButton>>callSelectionCallback:

 

Important ist OSToolItem>>#wmCommandChild, it calls self postEvent: OSxSelect data: (OSInput widget: self).

 

Under Vast 8.5 the squence is the same after double click release. single click release calls only

<11:44:24.051> OSWidget>>#postEvent: 3

<11:44:24.052> CwBasicWidget>>#callButton1Up: 

and the selectionCallback is not called.

 

I compared OSToolBar style of the two implementations, found nothing.

OSToolBar windowClass is ToolbarWindow32.

 

To the single click seems the toolbutton not to react, as if it is disabled. But with some method calls logging to transcript we see the button is pressed and immediatly released.

 

Juergen

[Juergen Koepp]

When the windows button is not keeping its pressed state while I still hold my mouse button pressed then it's no wonder that when I release my mouse event there is no button up event triggert when the button is not pressed anymore.

 

So the real problem may be that the button is not keeping the pressed state and is instead in a milliseconds switching back to unpressed state.

[Juergen Koepp]

After further tracing I wondered about OSItemHolder>>callWindowProc: 2304  with: 0 with: 0 just at the moment when in vast7 was nothing happening after a mouse-down click (still holding mouse pressed). So I made the following trial and it works, the button is not immediatly going up and when releasing the button CwToolBar(CwToolBar)>>callSelectionCallback: is triggert.

 

OSToolBar>>#callWindowProc:with:with:
 msg = 2304 ifTrue: [^0].
 ^super callWindowProc: msg with: wParam with: lParam

 

So what is WM_Message 2304 = 0x0900 ?

Who needs it?