Annoucing a RegEx LC program some may find useful

[Ed_Ray]

I am not sure if this the place for this since the Announcement post area seemed more for LC company announcements rather than for individual program submittals, but here is an announcement for a program some may find useful. I have also submitted this through the "Sample stacks" selection on the IDE menu.

I just wanted other Livecode users to know that I created an app “appropriately” called: “RegExOneStopShop” that addresses ALL the main issues and many side issues that I and many others have brought up in this and other forums regarding the inadequacies found in the Regex related Live code built-in functions from the time of their first inception into Livecode through Livecode 9.

Sections [1] and [1.3] of the document titled “Documentation for using RegExOneStopShop” covers all these related details.

Instead of many disparate functions it’s an all in one solution with simple to detailed reports ranging from a single simple page to over 100 pages of detailed results color coded for ease of understanding the related regex matches, main headings and regex replacement entries.

Section [1.2] has an exhaustive list of the many regex related program benefits. We recommend a quick scan through this list to kindle your inquisitiveness. In addition, the program supports multi monitors in relation to be able to move the app through N monitors with distinct resolutions while maintaining the SAME physical app window and control sizes across all these different screens. It even does this scaling on a single monitor automatically, if the user changes the screen resolution size on-the-fly.

The documentation includes a quick “Regular Expression (RegEx) Refresher” for those whose basic knowledge may have dwindled over time or for those wanting to become more familiar with general RegEx functionality to make the best use of this program.

The source code has been tested in all versions of window, Linux (Mint and Ubuntu distros) and in Mac OS 10.11.x El Capitan. Livecode versions 8 and 9 were used for testing and code construction.

All the needed program and related data are found in a single zip file called “RegexOneStopShop.zip” which can be downloaded from this link: https://1drv.ms/u/s!Arl3iluYwztdglD6DQQPmjVNBIfY

If the user wants to preview the FULL documentation prior to unzipping the zip contents and have full use of documentation links and other navigation aids regardless of their operating system or their desktop word processing app, please use this link: https://1drv.ms/w/s!Arl3iluYwztdglFEFZJaR-6ITRsM

For those users wanting a QUICK START please start with the “readme.txt” file once the contents have been unzipped.

Four test cases have been included to familiarize the users with the program. The readme.txt file provides basic knowledge of these test cases while the full documentation contains the details for the test setup, test type selection and the related test results. It is highly recommended for all users to run all four test cases and interpret the corresponding results PRIOR to inserting their own test cases because in doing so, the users will gain full confidence in using the program for their benefit.

Lastly, the file “Text bkgnd colors details & issues” NOT discussed in the readme.txt file to keep the starter readme information as brief as possible, describes in detail all the issues and problems that exists even at this point ACROSS distinct OS (Windows, Linux and Mac) when copying text highlights (colored text backgrounds) from the app’s test results page inside Livecode to subsequently paste them OUTSIDE of Livecode into word processors for subsequent use once the Livecode app closes.

Built-in and “work around” solutions are thoroughly discussed regarding what works and what does not work.

Hint: The “work around” solution provided by the program is working significantly better across all supported OS’s than the internal Livecode built-in solution as specified in the file with actual hands on test case evidence proving this to be a fact not just suppositions.

I am currently involved with some heavy-duty consulting, manage various software/requirement groups and teach at various institutions so I probably won’t have time to address most issues coming from the use of the program other than the program breaking and things of that nature in which case I would try to respond under those circumstances but I probably will steer clear of long winded rambling “philosophical” discussions etc. regarding its use. Everything that needed to be said regarding the programs intent and need for existence has already been clearly specified in Sections [1] and [1.3] of the documentation.


Thanks
Hopefully most will find the program to be useful and helpful. Various test groups outside of Livecode have found the program to be very useful to the tune of over 80% of these initial test users per my collected data and feedback. These particular testers/initial users, used a corresponding executable since they had no desire to manipulate the source code or have Livecode installed on their systems.

[MaxV]

Hi,
I didn't understand your work.
Did you produced new RegEx functions?
Where are they and how I incoroprate in my stacks?

[jameshale]

I would love to explore your stack but I cannot keep it within my screen.
I have a 5K retina iMac and when I open your stack it is TALLER than the screen!
The stack size is some 1900 x 2100 pixels.
I open the stack inspector and reduce these values but then I see there is a group which also needs to be adjusted. Not to mention all the fields.
Anyway in attempting to adjust they revert!
Checked the card script, seems user can resize stack.
great.
No
Stack still reverts to bigger than screen.
Why can I not make it smaller.
It does not need to be this big.
It does not need all the resizing code.
I noticed code looking at screen resolution so I tried changing my screen resolution too.
Yep, you stack adjusted itself each time.
Each time being bigger than my screen.
Please make a smaller version (like the images you show in your docx file.)
I notice they are windows like screen shots. Is that the problem?

BTW I am using LC 8.16

[bogs]

I haven't downloaded the stack, but can't you just set the scaleFactor to reduce the size?

From the 8.x dictionary

Examples
-- scales the stack to half size
set the scaleFactor of stack "myLargeStack" to 0.5

Thats what I would try.

[jameshale]

Thanks for the suggestion Bogs.
This does work.
Unfortunately the reduces the actual text in the fields too making them a tad difficult to read.
But I did get to play with trying to resize the stack by dragging from its corner.
The resize last about 10 secs before it jumps back to its original size.
Diabolical!

[bogs]

You might also look in the dictionary for the term "scale", among other things, it brings up just about everything relating to scaling to size.

Another tact you might try, since you said the text in the fields were too small is setting the text size of either the stack or fields to a larger size, if you have access to the code, or (if you can bear it) set the os's default text size larger, at least while using this program. Offered only as a work around.

[jameshale]

OK, so I went through the preopencard handlers for both cards.
The scripts grab the screenrects() of the monitor.
For my iMac, this returned "0,0,2880,1620"
This is correct (well apart from the menubar width) so the scripts had the right starting point.
But to be honest after stepping through and seeing all the checks and balances for situations that were not applicable to me I thought, "stuff it!"
I then did a replace all on "screenrects()" to "0,0,1440,810" so that the scripts thought my screen was half size.
Sure enough after sending a preopencard to the card the stack resized (including all contained controls) to a more manageable (and STABLE) 1125 by 1181

[bogs]

Yah, sounds like they needed to use either the working or the effective screenRect as the defining layout, depending on the device being used. From the dictionary:

Adding the working adjective to either form returns the virtual co-ordinates of each screen's working-area. The working-area of a screen is defined to be the area not covered by OS furniture (such as the task bar on Windows, and the Dock and Menubar on Mac OS X).

Adding the effective adjective to either form returns the area of the screen the application has to itself. In particular, if the keyboard is activated, it take into account if the keyboard is taking up space on the screen. (Android and iOS only)

You could do this, instead of changing the dimensions yourself if you want to test it out.

The solution you arrived at would certainly also work, but I'm curious about the placement.

I then did a replace all on "screenrects()" to "0,0,1440,810" so that the scripts thought my screen was half size.

I have no idea how many screenRects() statements there were, mind you, but in your case why not on any of the start up parts of the script (preOpen/open Stack/card) either set the screenRect manually there or use an if/then to say if it is x,x,x,x then set it to (it/2)

That way it is in one spot, easily removed or modified. You get the idea

[jameshale]

There are two card scripts. The first uses the function 10 times, the second 14.
There is a lot going on.
I thought this was an example stack of some regex functions.
But no, it is something else.
When I did try the first example I was not expecting the video display that I got.
I will look at the docs later on before venturing further.

[bogs]

When I did try the first example I was not expecting the video display that I got.
I will look at the docs later on before venturing further.

Yah, by all means.

I was just trying to say, for example, that with 2 cards, and a total of 24 functions, instead of modifying all 24 functions, you might stick a simple manual or conditional change of the screenRect in say, the open or preOpen default stack script

I really should have just downloaded it myself and tested out my theories, my bad