https://forum.blackboxframework.org/
Of course, I had forgotten that (I use CtlsSliders.NewCharField from the CPC site).Josef Templ wrote:@1: it is not possible to link to a CHAR, only ARRAY OF CHAR works.
Code: Select all
modify := Controllers.modify IN msg.modifiers;
GrabMark(m, r, f, msg.x, msg.y, ~modify);
IF (m.kind = tabs) & modify THEN
Ivan, In principle I agree that importing HostPorts in TextRulers should be avoidedIvan Denisov wrote:I am adopting some of Center features for Obertone Freenix version of BlackBox.
Importing HostPorts to Text subsystem is bad idea. It breaks hermeticity of Text subsystem.
Better use Ctrl key in Track procedure.
Ctrl was used to add vertical line. Now it is also can be used to add vertical lines with new dialog window. So there is not much inconvenience in that change.Josef Templ wrote:Ivan, In principle I agree that importing HostPorts in TextRulers should be avoidedIvan Denisov wrote:I am adopting some of Center features for Obertone Freenix version of BlackBox.
Importing HostPorts to Text subsystem is bad idea. It breaks hermeticity of Text subsystem.
Better use Ctrl key in Track procedure.
but I didn't find a better solution.
The problem with your approach is that it changes existing behavior.
Both, extend and modify, are already used for tabs.
I like this idea, because initially (I guess) BlackBox was aimed for mac with only one mouse button. So there is lack of basic controls states. The "context" can help in many cases.Josef Templ wrote: A clean solution would require to add another high-level modifier for mouse-right clicks to Controllers.TrackMsg.modifiers.
Something like 'context' (or 'menu' or 'properties' or 'popup') because mouse-right is usually used for opening a context menu of an object in the Windows GUI.
A simple and 'compatible by construction' approach would be to use the constant 18 (HostPorts.right) for that new modifier.
This effectively raises the platform specific concept of a mouse-right click to a high-level concept.
The ugly point here is that until now the platform specific modifiers are >= 16 (by convention) and this no longer holds then.
A cleaner approach therefore would be to add a new constant (e.g. context = 3) that is included in modifiers together with
the platform specific value HostPorts.right. I don't know if this causes any incompatibilities in existing mouse tracking procedures
but probably it will work without any problems.
Right. It solves, for example, the same problem in DevDependencies.Ivan Denisov wrote: I like this idea, because... The "context" can help in many cases.
This sounds like the start of a good solution, but, for me, the main part of a clean solution is to improve the Docus.Josef Templ wrote:A clean solution would require to add another high-level modifier for mouse-right clicks to Controllers.TrackMsg.modifiers.
Something like 'context' (or 'menu' or 'properties' or 'popup') because mouse-right is usually used for opening a context menu of an object in the Windows GUI.
The platform mapping should be added to the P-S-I document, I think.Robert wrote: The mapping is given in System/Docu/Controllers, but not as clearly as I would like. I can't find this platform specific mapping in the PSI document. I thought it was mentioned in some higher level user manuals, but can't find it now.
I would like to see a clear table giving the full mapping (for Windows, and any other platforms where it makes sense). This table could be in one place, with links to it from other places where these ideas are currently mentioned.