Blog as part of email chain.

Dictionary Data Type

Hello prof Becker, you were recently asking about global dictionary issues.

I thought I would continue our email with a timely regurgitation of blog verbiage. But first, happy Easter. I got you a cookie. Yum.

->insert cookie here<-

(In my case,) I refer to the great and mighty All Dict. More accurately All Dict 2.0. 😊 The second part here of the blog shows the definition of a Windows link used in the app.

What I need is a complete definition of MP3 files I can rewrite that’s web enabled. (hint. hint.) Something open source preferably.

However that assumes (as in your case) that at the Mdm.Oss.File.Type level the DictAll is implemented. Regardless of language and specific to my legacy code. So hypothetically… and also ignoring existing tools and standards organizations.

What is important is that DictAll (Meta data about types, including documents and dictionaries)… or relevant about meta data generally is that you just define that as another data type.

You always have an abstracted concept about any data or class (entity) that you are creating an abstract class to handle it. It’s a cycle of self-referentialality that I hope Douglass Hofstadter would be proud of. Were in not in C#.

https://en.wikipedia.org/wiki/Douglas_Hofstadter

Gödel, Escher, Bach - Wikipedia

but first, my random weekly report.

Weekly Status

The bug list I am on currently includes

1. Correct and verify Base, Db and App form status and buttons.
2. Link StateViews are using the Script data type.
3. Min line height on StateView header and footer.
4. Form close leaves residual system tray icons.

#1 App form status and buttons: Threading requires a call on the form UI thread.

The form updates its unique controls in response to status changes and data.

It may in turn call corresponding functions in the File objects.

And then a more general database task (and related run control buttons and fields).

Below this is the calculation task (not called).

#3 Min line height on StateView header and footer: I think it was causing problems with auto-sizing.

#4 system tray icons: The end goal was to:

1. Have a Tray icons control available within any form per the Console.
2. Move the tray Icon code to framework (FW) Tray UI control.
3. In turn, move that to the RunControlUi component.
4. Easily hide or show them. Example, show the Errors icon on error.
5. Overall, that code needed review and standardization.

In terms of functionality there are icons for each app form, the clipboard and Console 5 message types. It becomes a component optionally with show/hide on click icon and potentially a context menu in each case.

I am doing this while fixing 1–3 to save a little time. (why) This system is a complete dog, if newish, but with a bad video driver AMD won’t fix for HP. VS barely runs and lags dramatically. It’s a long story. I get the hw nobody else can use here.

Standardized Data Types in the FW

In an ideal world you only define data types and Main form data processing “xxxDo” function loops. Two steps.

I) New effort would be limited defining and extending a file type(s).

II) A new app would be limited to defining the a) Form and b) Do loop.

Partial list of crosscutting domains and concerns (name spaces).

In this app we are looking at the Shortcut or Link definition. It has the following fields and objects. It is shell enabled.

With any data type we implementing a core and optional interfaces (Ie serialization).

The Link implementation.

The FW defines Std or optional interfaces and a type implements:

i) The Db CRUD & validation.

ii) Db SQL functions.

iii) GridView Row Data or Row Control for the UI.

iv) Serialization.

v) Clipboard interaction.

Problem: The current way Row Data is returned as a string or object arrary This was inadequate for cells that contain form and custom controls.

It is retained for supplying drop down lists and help text as well as simple string or numeric data. Having a lightweight component is per design.

The cell specific row definition in the (and other) app (form) control creation gets moved to any given data type, meant to become a default and/or base call defining a GridView.

[ed.] I am moving (and renaming) all standard or custom controls to the Mdm.Oss.Decl core per the revised architecture.

Note: In a utility FW Tasks can interact with optional standard Db fields. For example: Id, datetimeupdated, state, run & task, SRT or any functionality needing persistence, aggregation or cross linking.

Reason: Enhancement to use cell objects allowing drop downs and buttons. Mdm.Oss.Components. Coding this minimum UI standard allowed for delaying this task until any commercial release.

Summary

At the end of the day any product, the FW in this case, should perform its basic purpose well. So in this case (or my view) you should be able to rapidly define new types, views and processing apps.

It’s my hope that publishing what is proprietary design has been an in depth discussion of how specific requirements like yours can be quickly defined in code. IE a global dictionary. It might provide food for thought to folks out there working C# or data science.

Keep in mind my choice of RUST isn’t that I want to exclude any of Python, C#, C++ and also C. RUST is an OS development platform, C is something you want. If you include PICK basic, Javascript, Json, Markup and declarative type Types I think the (SRT) code conversion would qualify as modernized.

If this doesn’t help, any time spent not flipping through Instagram or Twitter couldn’t be all bad. I’ve got Putin on hold and he sounded grumpy. I have to run. Talk to you later. Dave H.