I have quite recently ported my software to A-Shell although a long time AMOS user. We did a lot of work some years back developing an interface with AMOS and Windows using .NET. Now in A-Shell I have been exploring various Windows interfaces including mouse detection and enhanced screen input/output. I use my own version of INPUT/INFLD which, in conjunction with the applications allows the user to click around menus, data entry screens etc. I have found though that using the enhanced, proportional font, print statements d/e/tprint that the mouse click detection, on those parts of the screen, stops working. Any feedback would be appreciated. I have a simple, sample program to demonstrate this if required.

Welcome to the Forum Eddie!

I haven't had a chance to review your sample program yet, but let me comment that there are two or three separate mouse click response mechanisms, leading to some inevitable confusion in an environment like you describe (which sounds like a mixture of the traditional main window / plain text grid and GUI objects).

1. Traditional mouse click reporting (see MX_MCRS) - this works only when the click is sensed by the main window (rather than by a GUI object overlaying the main window). This requires the application to actively query the click information and decide how to respond based on the coordinates and type of click.

2. Automouse - this works only in the main window with standard fixed pitch text. The idea is simply that when you double click on some text, A-Shell attempts to identify the boundaries of the token and then transmits it to the keyboard. This is a painless way to support mouse clicking in screens where the normal keyboard options are visible as text (like in menus, or in display lists where you can enter the identifier for one of the records to get more info.)

3. AUI click events. You have some options about what happens when the user clicks on a GUI object, but the event takes place automatically; the application doesn't get the opportunity to intervene. And when a click occurs on the GUI object, the message does not filter through to the main window where MX_MCRS could be used to sense it.

A further complication is that TPRINT / DPRINT / EPRINT, while providing an easy way to create GUI objects, don't provide a way to specify what the click event does. For that, you need to use the full AUI_CONTROL or AG_CONTROL commands.

The problem with mixing traditional mouse click reporting with GUI click events, besides having to have two completely different sets of logic, is that, at least in the case of text objects, the user can't necessarily see the boundaries of the objects, which could make it difficult for them to know what to expect by a particular click.

Thanks Jack. Understood. Maybe, this is not the method for me then. I had been using your tab(-10,68) utilities to create different shades for text, menus and data but hoped that the proportional text and sunken fields would provide a more Windows like appearance. All my software is event driven (i.e. the user can click around the screen and get responses). I'm not too sure how I would have dealt with moving the cursor around a proportional text field anyway.Can you suggest an alternative way of acheiving the appearance of sunken fields?

BTW I have, foolishly, posted this twice, here and on the general Windows page, doh! I think some of the earlier references to people being stuck in their ways applies to me too.

Tesssting sending an attachment, sample screens.

How it might look using e/dprint

I told you that we are fast here
(nice screens )

Cheers, still try to retain 24*80 but with all the features of Windows. We wasted a lot of time creating the .NET/AMOS interface and now I'm catching up.

Sample program but I think you have answered my queston Jack. Compile with x:2. When we first met this could have been in a bar table and kept us amused for hours!

I actually struggled over that problem myself, trying to figure out why TPRINT, DPRINT, and EPRINT were acting like ordinary PRINT. At the time it seemed like a good idea treat them all as PRINT when compiling under the original COMPIL (without /X:2).

But your sample program also through me off by not containing the TAB(-1,158) command to activate click reporting. Once I added that, it works fine, except when you click on the GUI fields created by T/D/EPRINT. Which I guess is what you were complaining about in the first place.

If you're want to use the GUI objects, then a couple of things will have to change...

Since T/D/EPRINT don't give you a way to specify the click event, you'd have to switch to the full AUI_CONTROL or AG_CONTROL syntax in order to specify what gets sent when the object is clicked. Typically developers use the VK_xF### scheme to send virtual function keys which are then picked up in the exitcode parameter of INFLD, XTREE, EVENTWAIT, etc. (The virtual function key sequences could also be interpreted byte-by-byte like you doing for the mouse-click sequences). Or you could program the click event for the GUI objects to mimic exactly what the mouse cursor reporting sequence would be. Since the full AUI_CONTROL syntax is a lot more detailed/verbose than the PRINT statements, you might want to create wrapper functions to simplify the conversion, maybe something like FN'PRINT(row,col,text{,clickstring}) where the default clickstring would be based on the row and col parameters to mimic the mouse cursor reporting.

Alternatively, although it would require a modification to A-Shell, it's not out of the realm of possibility that a configuration option could be implement to cause A-Shell to forward the click event from the GUI objects to the main window if the GUI object didn't have it's own click string. In that case the behavior of the mouse click reporting would be unaffected by the use of T/D/EPRINT vs regular PRINT.

On a related aside, although the AG_ATTRSUB trick for changing the behavior of the underline attribute might be a quick upgrade in some situations where you don't want to go all in on GUI, you might also want to look at the so-called 3D TAB mechanism for a more comprehensive/flexible approach that maintains the more-or-less traditional PRINT TAB() syntax.

Yeah, I try to trim down sample programs and chucked the baby out with the bathwater with losing the -10,158 bit. A 3d tab for both sunken fields and also raised ones for menus would be realy useful to me. Take care.

OK with the dropped tab back in

Just to be clear, the "3D" isn't referring to 3 dimensional in the sense of raised/sunken, but in the sense of taking three arguments (row, col, and a code that indexes to a set of predefined attributes, including color, type style, sunken, etc.)

Understood re 3D

As a heads up, I'm looking into what it would take to support mouse cursor reporting in T/D/EPRINT objects. If not too messy, that might make sense for your scenario. I'll make a decision on it in a day or two.

Here's the beta update which supports the TAB(-1,158) mouse cursor reporting sequences when clicking on T/D/EPRINT objects ...

ash65notes.txt
ash-6.5.1702.0-w32-upd.zip
ash-6.5.1702.0-w32c-upd.zip

Impressed.I am in new territory here and may need a bit of gentle handholding. I cannot directly execute the ash-6.5 zipped files. I get vic32.dll and ashicol not found messages. I am currently using 6.5.1687.1 Can someone please advice how to access a download via your site or am I just doing something stupid? ): Can I use the downloads section on Microsabio.com or elsewhere?

Maybe I just copy the .exe to vm\miame\bin? I'll try that (:

That will do the trick

Cheers Steve, it did. I'll give this a good testing and get back.

Looks good so far (:

Regarding the zip or tz updates, typically when changes are first introduced, they only affect the executable (ashw32.exe or ashell for Linux) and so to save time I initially post just that file (in compressed form). So yes, the procedure is to just un-compress it on top of your existing executable (ideally after making a copy of your existing executable just in case you want to quickly go back to it). Of course for this technique to work, you need to start with a reasonably recent full installation. (Dropping the 6.5 executable on top of a 6.4 set of bin files may only partially work, leaving some of older DLLs unusable.) After a reasonable beta test period, I'll build a complete install/update package which you can run from the regular /dist/<platform>/ directory, or, eventually via the Help > Update menu. (Since the Help > Update menu feature is exposed to virtually all end users, we try to be extra cautious about making updates available that way, until they've had an appropriate amount of field testing. The threshold for 'appropriate' is naturally higher for the 'stable' release than for the development release.)

Cheers Jack, it's all working fine so far, got a little bit of work to do but I'll let you know. Thanks for any other comments/help. Looks like the A-Shell world is a good place.

Congrats Eddie on a successful port!

(Just don't hold us responsible for Herman... )

Wait a minute, now. Be polite to your elders!

Cheers

Thanks to A-Shell enhancements I have all but replaced our earlier .NET interface to create screens to front our interactive applications. Still need a bit of work for sub-forms, memos,multiple line forms etc. but close.Thanks so far.

Doh, little screen glitch on sample, but you get the gist.

Looks nice and clean. (I'll notify the order processing department to be ready for a deluge when your potential customers get a glimpse and start a run on it.)

Hi Eddie - having been in your shoes i know it will take a while to get all the hooks in but looks good so far! Just a friendly recommendation, on your front/menu screen, replace all your fixed font / 80 pitch text to some nice proportional font, even use some different font size, bold, etc to give it a nice upgrade. Not much effort but will help get your menu out of the 70's

Thanks Frank, of course some of us were writing Alpha Basic in the 70s !. Did you use 3D tabs for changing fonts? I have also (as I am sure all have) created all sorts of output stuff PDF, XML Excel, Drill downs etc.interfaces with email, outlook etc.It will be interesting to see what some of you have been creating. Have a good weekend.

Does the 80's count

Our first GUI version ran on both ATE and CRT. That must be where my hair started looking more like Hermans'

I tried all sorts of things, sunken fields, etc.. i have found personally that you don't want to use too many variations of fonts, etc or it can look "gimicky". Just some different sizes for emphasis, and some well placed graphics. We have moved to "hover menus" for our main menu. Happy to help.

PS: Another idea to help transform your programs would be to place your infld / edit controls into some sort of container, like a dialog or tab (we use the latter). I realize you are just trying to get going but this is also a good way to get past the old crt 24x80 look.

Attaching a simple data entry screen sample as an example.

Congratulations Frank, I love "the order" in your screens, always, very elegant and modern.
It's noticeable that every pixel was thought and approved, those screens guarantee sells, for sure.
Eddie, if you're looking for directives to GUIzation, follow Frank, in the short term you will not be able to stop with such wonderfull results and not that much effort for convertion.

Nice one Frank, I've still got much to learn. Can you give me pointers e.g. creating the text tabs at the top (notes, contract etc.) I am not adverse to reading the documentation and sample programs.

Cheers Eddie

Thanks Jorge! Wow i can certainly not live up to those kind words Truly my screens are just the beginning, when you are ready to push the GUI envelope, look at Jorge's screen examples! They will make these look like first grade! (Jorge maybe you can publish one here just to show Eddie the sky is the limit here!)

Eddie - thanks... I am happy to give you any pointers here as will any one of the great group of people here! Don't be afraid to ask!

We are using a control Jack added a few years (8?!) ago called TABX. It has lots of cool options including colors, and tab placement anywhere on the screen. I found this to be a good way to organize screens with multiple options. We have gone with this look as the main screen field "container". Some like Jorge use the main system window and populate with literally hundreds of gui controls, all related to the user task. It depends on the overall focus of the program. Since our system is derived from text-entry (like yours) this seemed a good approach.

The key to your screen designs is to maintain a parent/child relationship with all the GUI controls. If you populate a tab as your main screen, that becomes the parent, and any control inside that become the child, and so on. Child controls are relative to the parent as far as positioning and how you add them. I think the best way to get your feet wet would be to write a small stand alone program for you to play with, then figure out the best way to back it into your business code.



TABX Link

Great, many thanks, I'm on it

I've been looking at tabx and have now got to grips so far on my prototypes. As I am discovering, using d/e/t prints, tabx etc. we are dealing with 'controls' and these do not seem to always behave as I would prefer (in my nievety) with traditional screen displays. My problem is maybe that I have invested so much in incorporating mouse clicks with my data entry, menus etc to create interactive applications.

I am quite happy to continue with trial and error but would like to achieve, for example, drop down or 'combos' as I had with traditional and even with proportional font stuff. Since converting to A-Shell I have used various methods of creating menus, drop-downs, displays etc.including tab(-1,68) (with underline), tab(-10,15) to set RGB and 3D tabs for various colours and fonts.I am now using tabx to create my main background using Groupbox for the white background for combos. I would like to achieve the light blue bar when scrolling down. Any pointers?

Thanks, Eddie