Bruce developed a norm for Data with NAME() pipes.
We have added expressions to our NAME values which amount to macros to be processed.
We have used the EVAL(‘statements’) and SCRIPT(‘statements’) statements as the delimiting commands.
Does Bruce have any thoughts on this as the published docs dont seem to cater for this.
Please change the title of this thread. Named Pipes are a completely different Windows thing - the term you are looking for here is Extended Name Attributes.
Secondly, You are free to use whatever extended name attributes you like in your code. If you’d like to share your use of the attributes though feel free to write up what you are doing, and perhaps some example of the use case, sample attributes and so on. It’s a bit hard to infer from just EVAL and SCRIPT what you are doing.
Lastly the goal of the proposal was not to document every possible use of extended attributes. Just like the documentation of classes does not specify every possible class. Rather it’s a proposal for a technique - which you seem to be using so good for you.
Feel free to share more details about what you are doing.
Cheers
Bruce
Thanks for the reply. Looks like someone changed the title already…
Well we thought the use of Name was a brilliant idea where a Data Dictionary wasnt present In Memory.
We are currently trying to get some kind of List box formatter working as using the NAME attribute to supply some information about the field in Queues.
Lots of our Windows going forward will be pure runtime and a lightweight formatter for list boxes is going to be must have.
We have a basic working version where the attributes are processed by EVAL and will be extended to support runtime script expressions.
We watched the you tube video presentation and though it was a great way to add information for reflection.
Yes badly titled not an expert on Winsock or pipe Servers and pipe Clients.
Since you’re already in the name, why not include a FORMAT() for that field that you can include when you build your FORMAT() string? Carl demonstrates the FORMAT() pieces pretty well here GitHub - CarlTBarnes/List-Format-Parser: View LIST FORMAT() split into One Line per Column. Use for Edit Format, Copy Columns and Groups. Source compare: Format() column changes, Preview LIST in Window.
because the result of the EVAL or script feeds a queue of information to a list format builder class that then returns a string for use with format…
it assumes the user is going to define their own window control views using a GUI View manager.
the classes are already built… the last step is the little list format window for the user to select the fields to view.
The list formatter is to provide a basic view of a list.
Coming from an accounting back ground i can tell you that the end user has a VERY VERY short attention span. Dont put more that a few options in front of them or me…
At the moment we are only testing an evaluate compliant procedure to set some basic properties on a flat queue.
The same procedure can also be processed by an expression engine for more complex statements.
That wonderful example looks very interesting with a comprehensive model and certainly im sure some parts of it would be very valuable for developing runtime list box format solutions.
one problem with ABC generated queues is that the fields for colors ect are all included and we dont want to see these from queue reflection… doesnt apply to hand coded queues where colors are applied by callback procedure in a virtual queue.
I have a Class that will take a LIST,FROM(Q) and feed it sample data using a VLB. It deals with all the modifiers like colors and styles. I used it for my window previewer
Looking at this - if we get some time …all very interesting examples.
WindowPreview/CBWndPreview.inc at master · CarlTBarnes/WindowPreview · GitHub