Method string view part

[Bob Nemec]

Hello, 

We're porting our VW application to VAST. I have set up queries to view VW method source history from our Store postgresql database. It works fine, but using AbtMultiLineEditView to display the method source is not optimal. 

Is there a simple way to show method source code that would add VAST highlighting?  

This is read-only; we're only using it to view old methods. I'd like to keep it simple... I have years of VAST experience, but it's dated, so this may be a simple question :-) 

Thanks for any advice,

Bob Nemec

Software Architect 

KORE Solutions 

[Louis LaBrunda]

Hi Bob,

I don't know if you will consider this simple but how about putting pieces of the following instead of the AbtMultiLineEditView.  

| workspace codeThatYouReadFromYourDatabase newCode |

workspace := StsWorkspace new open.
codeThatYouReadFromYourDatabase := WriteStream on: String new.
codeThatYouReadFromYourDatabase
nextPutAll: 'bobCode'; cr;
tab; nextPutAll: '"Bob Code Comment."'; cr; cr;
tab; nextPutAll: '^true.'; cr.
workspace stsInsertString: codeThatYouReadFromYourDatabase contents.

At this pioint you will have an open StsWorkspace.  You can edit the code there.  When you
know the poolDictionaries (you can do this at anytime) you can add them like so:

EtWindow defaultEvaluationPools: (EtWindow defaultEvaluationPools asSet addAll: #(#SstConstants #SciSslConstants #NlsCatSSTG)) asArray.

The open workspace will allow you to edit the code as if they are defined for your target class.

When you are finished editing the code use the code below to get the new code and compile it into your new method.  You will need to add any new poolDictionaries to the class first.

workspace textWidget selectAll.
newCode := workspace textWidget getSelection.

TheClassYouWantToAddTheMethod class compile: newCode.

Good luck.

Lou

[Bob Nemec]

Thanks, that works nicely. Can you point me to how to add an StSWorkspace to my AbtAppBldrView subclass view? 

I spent ten years working with WindowBuilder after working with Composition Editor for only a couple of years... back in the late 90's. I'm sure it will all make sense again soon :-) 

[Louis LaBrunda]

Hey Bob,

I'm not exactly sure what you are asking but if it is what I think, the textWidget is an instance of StsScintillaEditor, which I think does most, if not all, of the work.  So, maybe you can get it to be a widget in part of a window.  I'm not sure what you would have to do to make the poolDictionaries work.

Lou

[Bob Nemec]

I've decided to go back to what I know and subclassed EtAbstractMethodsBrowser. It will take me a bit longer to get comfortable with AbtAppBldrView & Parts again. Thanks again for your help.

On Saturday, April 4, 2026 at 9:19:06 a.m. UTC-4 Louis LaBrunda wrote:

[Louis LaBrunda]

Hi Bob,

Do you really need to make the window you work on the code in part of another window?  You can put the code that reads and fills the workspace in a window with some code to compile the method.  A click or two in the main window, edit the code, go back to the main window to compile.  Next method, rinse and repeat.

Lou

[Marcus Wagner]

Demands to provide a VisualAge part offering syntax based structured code presentations (based on Scintilla) pop up from time to time, but are not realized up to know for obvious reasons.

Architecturally its like demanding a fundament on top of the roof of a house. Is like a hen - egg problem. Or to ask for a part encapsulating the VM underneath, running the whole contruct above. Or asking for multiple inheritance.

The existant code manipulation is the target of the tool environment (EtWindows etc) where the VisualAge Part world is built upon, under the implicit general requirement, that any tool support has to be removable underneath later on, at the end of the development phase, providing a runable application without development artefacts (the process of packaging) or to create a runtime image.

And another reason of this is its complexity. For a fullfillment, such a part would depend on too many things, thus being not being maintainable economically. The trend here is even that this becomes worse recently, by integration of AI (and the whole infrastructure to provide this) underneath to support coding. 

A short survey of this aspect:

• Scintilla is not a widget in isolation, it is nurtured with language descriptions (rules, grammar), depends on DLLs etc., given from outside. This depends on all the syntax language details. 
  Smalltalk is here rock-steady, little fluctuations here since decades, but compare this to other languages and there frequent changes.
• The feature depends heavily on graphic capabilties of the OS and this is in conflict to the strive of platform independency of Smalltalk. This is a permanent issue (e.g. Windows multi monitor, Wayland instead of X-Motif etc.).
• All code panes in the development depend on this and sometimes this fails persistently (since the beginning of its introduction). As a compromies, formatting is not offered everywhere.

Any encapsulation of this complex issues in a Visualage part endangers the break down of the existing complexity of the visual programming approach. To give an example (imagine consequences by yourself):

given the EtBrowser structure (base coding support), add Q&A tools (formatting, etc), add colored representations, add generator support (VisualAge e.g.) think about the in a mess cyclic dependencies with polynomial explosion (widget with /without formatting, widget per OS and OS graphic support system, hardware). 

Given some strict base concepts (like strict hierarchical prerequisites) wont let you solve this. 

To achieve the given existing reaslisation, the Scintily Support was added as a removable plug in, wherever it was needed, but not as a standalone application which could be selected as a prerequisite.

Given this, providing such a part would structurally imply that all the development related things (compiler, debugging, etc) would be forcibly integrated in any application making use of such a (ficticious) code view part.

Sometimes that succeeds, but up to know this is a nogo in packaging, on the way to provide a runtime image.

In the past, I remember this as night mare. To find out the reasons why the development enviroment was magically included in the packaged image, although it should not.

To make it clear - the color code support in the development is extremly helpful and a valuable benefit. 

However the path how that has been achieved cannot be easely applied to or taken over in other architectural structures (like the VA part universum).

 

Kind regards

M