Copy link to clipboard
Copied
I have been tinkering with regex for the past week attempting to find validation scripts for both the Military Date Time Group (DTG) expressed as DDHHMM(Z) MMMYYYY -- with the (Z) being primary for Zulu time but modifiable if necessary and for fixed geocoords (LAT/LONG).
Thus far, I have only found lat/long regex but have been unable to get them working -- still attempting with the following example -- and I am still looking for DTG.
lat/long example:
If anyone has previously skinned this cat, my sincerest thanks in advance for an assist.
PS Apparently, adobe does not like the regex example I attempted to post. :S
The Reg Exp you posted was invalid. I tried to fix it, but not sure it worked...
You can use this code as the custom Validation script of either longitude and latitude fields:
var reg = new RegExp("(^\-?\d+(\.\d+)?),\s*(\-?\d+(\.\d+)?)$");
if (event.value && reg.test(event.value)==false) {
app.alert("Invalid value.");
event.rc = false;
}
Copy link to clipboard
Copied
When you refer to using regular expression, what exactly are you trying to do?
DTG is very complicated to do with JavaScript if your PDF will be distributed accross different countries (regions and timezones) because of the timezone-dependent offset value.
See here: https://special-ops.org/military-time-military-date-time-group-explained/
Whatever the user enters in that field, the core JavaScript interpreter will grab a timezone from whichever Network Time Protocol (NTP) server is setup on each user's computers (date/time settings) and will append the offset value as part of that timestamp.
But if this is a PDF that will be used to disseminate a task to subordinates (i.e. issuing orders), and the DTG field would be timezone-independent, then is fairly easy to customize with a script, for example.
If you have a script try sharing it again please or do a screenshot of what you have on screen.
And would you also mind clarifying what do you mean by latitude and longitudes; that is a whole separate thing from DTG unless you're referring about the timezone offset values that you want to append to the desired DTG date.
Copy link to clipboard
Copied
Thank you for your time and your response. I'm actually looking at two separate validated fields -- one for lat long and one for the DTG. It was asked if I could somehow account for the local alpha character timezone designator to which I said I'd look into it -- leading to my initial help request. I also told them I would prefer to stick with Zulu time only as the lat/long ship's position would clearly indicate the time zone -- potentially just a little more work for those accepting the report forms.
As these forms will primarily be used offline while underway, Zulu appears the easiest way -- and written orders are never issued in local (L) time, always and only in Zulu. I merely wish to validate the proper format is being entered by the user (ie. DDHHMMZ mmm yyyy & lat/long) to reduce fat-fingers -- of which I suffer daily. 😉
Here is the script I've been attempting to get working for the lat/long
<script type="text/javascript">
var latitude = document.getElementById(lat).value;
var longitude = document.getElementById(lng).value;
var reg = new RegExp^(\-?\d+(\.\d+)?),\s*(\-?\d+(\.\d+)?)$;
if( reg.exec(latitude) ) {
//do nothing
} else {
//error
}
if( reg.exec(longitude) ) {
//do nothing
} else {
//error
}
</script>
Copy link to clipboard
Copied
So you may be in luck.
I have done this before in one of my PDFs without the need to validate with a regular expression.
To make it easier on myself, I employed a regular date field with the built-in calendar picker but I used a custom format for the date of "yyyymmdd".
And as the user selects the desired date on that date field, the same date will be displayed in DTG format on another textfield that I placed adjacent to the date field.
I've also learned in this process that this alleviates the fact that, you will always run into users that (for some unknown reason to me) can't stop messing around with sensitive documents) , it eliminates the headache on how to teach them what not to do with the required workflow.
I will post back with an example of the util.printd() methid that I used instead of using regular expressions for this particular formatting.
You can evaluate if this works for you.
Copy link to clipboard
Copied
The Reg Exp you posted was invalid. I tried to fix it, but not sure it worked...
You can use this code as the custom Validation script of either longitude and latitude fields:
var reg = new RegExp("(^\-?\d+(\.\d+)?),\s*(\-?\d+(\.\d+)?)$");
if (event.value && reg.test(event.value)==false) {
app.alert("Invalid value.");
event.rc = false;
}
Copy link to clipboard
Copied
I had also been attempting to get the following working as well with little to no success. As you understand this stuff inside and out, you may have a better idea what this means.
function checkIfValidlatitudeAndlongitude(str) {
const regexExp = /^((\-?|\+?)?\d+(\.\d+)?),\s*((\-?|\+?)?\d+(\.\d+)?)$/gi;
return regexExp.test(str);
}
checkIfValidlatitudeAndlongitude("9.9824245,76.5703886"); // true
checkIfValidlatitudeAndlongitude("9.2323,1212notValid"); // false
Copy link to clipboard
Copied
Seems to be working fine, no?... However, I see now that this expression takes both values together, which means you also need to have a single field for both the longitude and latitude if you want to use it.
Copy link to clipboard
Copied
Ahhh... and in half a second you pointed out what I couldn't figure out. I was splitting it into two fields. With most of this, I have become the "script kiddie" borrowing snippets here and there, mashing them together, and continuously re-wickering them using Visual Studio Code in my attempts to get them working the way I need...
... clearly not the most efficient way to do things.
Thank you!
Copy link to clipboard
Copied
As for the part that I owe you, I think this whole project works better with a modal dialogue window.
So when the user clicks on the input field, the dialogue can guide the user interactively to enter the required info and display itcorrectly in DTG format plus the grid coords soon after they click on OK button.
Copy link to clipboard
Copied
That sounds absolutely awesome... and I have zero idea how one might implement that! 😉
Copy link to clipboard
Copied
I have a script.
Just so you are aware of, the proper syntax for the DTG format that you are asking for is customized like this:
ddHHMM\(z\) mmmyyyy
NOTE that for core JavaScript takes Zulu offset designator in lower case.
The same is true for days(d), month(m) and year(y).
Military Time is expressed as HHMM or HH:MM (upper case for hours and minutes to express an 24 hour clock)
And for a twelve hour clock the Ante-meridiem(a.m. or AM /post meridiem (p.m. or PM) you use hour with (h) in lower case (for example: h:MM or hh:MM).
Copy link to clipboard
Copied
Standing by for the script! 🙂
And my sincerest thanks for your assistance.
Copy link to clipboard
Copied
++EDITED REPLY, clarified a few discussion point and fixed some typos
Hi,
I've stumbled accross a few important observations.
I can't get to work around the regular expression provided by Try67 due to latitude and longitude not being the same thing.
I am going to need help from him to figure this one out correctly.
The current regular expression tests for a string of text which assumes that both of the latitude and longitude coordinates value will match the same pattern; but that is completely incorrect.
The issue with this validation is that it evaluates nothing but a pattern that doesn't factor in the positive (+) or negative (-) degrees for each gridcoord.
The validation should be able to capture the 5 main latitudes accross North to South degrees of the Equator line in the absence of "N" or "S" designators, and the West to East longitudinal 180 degrees from the Prime Meridian in the absence of degrees expressed with the "W" or "E" designators.
The current validation doesn't account for the 12 positive nor 11 negative longitudes to propperly capture all the East to West time zones (starting at 0 (12 midnight) and edning at 2300 hundred hours (11pm).
In other words, since we are not using degrees with the cardinal locations format, we can instruct a script to get the correct offset (UTC Military Timezone) just by using the decimal numeric values entered in the longitude and as long as they are prefixed by a "+" or "-" symbol.
That being the case, the current validation that we are using will not restrict users from making mistakes when entering the required data.
For instance, South of the Equator latitudes entered as a decimal number must be prefixed with the negative symbol and to the North of the Equator with a positive symbol.
This is also true for longitudes expressed as degrees to the West of the Prime Meridian, which must be prefixed with the negative symbol when using a decimal number value, and with a positive to the East.
That said, latitudes are 0 degrees to 90 degrees from the Equator line, but because we are not calculating degrees divided by seconds and seconds divided by milliseconds, when we use a decimal value for latitudes we cannot type in that value as "175.3645762".
For a latitude expressed in decimal notation it must be two decimals to the left of the decimal point. (i.e. -89.1265437 which equals to saying 89 degrees South latitude).
Coversely, Longitudes are from 0 to 180 degrees from the Prime Meridian (Zulu Military Timezone).
So, when we use decimal notation values to express a longitude, the digits cannot exceed three decimals to the left of the decimal point.
Otherwise, if I am at sea, the decimal value of "9.9824245" in your example is telling my crew to be where exactly? (-9.9824245 is a whole different location in the World from +9.9824245).
+9.8924245 equals to 9 degrees East longitude (to indicate 9 hours ahead of time from Zulu while -9.8924245 indicates 9 hours behind).
Also, note that to the right of the decimal point you are requiring your users to enter up to seven digits (not six).
Using 7 decimals to the right of the decimal point accounts for centimeter location precision.
This important detail is not captured by the regular expression as well.
So, I've been struggling to get this to work.
In the meanwhile, below is an example of a Document-level JavaScript to illustrate how to declare a function in a variable that will create and load up a modal dialogue when the user interacts with the target field.
// Declare a variable with a function
var dialog2 = { initialize:
function (dialog) {
// Create instructional text
var dateTimeGroup = dialog.store()["DTG"];
dateTimeGroup = "Fill in all of the required DTG fields : ";
dialog.load({ "DTG": dateTimeGroup });
},
// execute when user click on OK button or presses ENTER on keyboard
commit:function (dialog) {
var results = dialog.store();
getField("Text13").value = ( results["dday"] +
results["dhrs"] +
results["mins"] +
results["zone"] + " " +
results["dmon"] + " " +
results["year"] + " " +
results["dlat"] + " , " +
results["dlon"]).toUpperCase() ;
// Validate the longitude and latitude output format and alert the user
var latitiude = new RegExp("(\-?(90|[0-8]?[0-9]\.[0-9]{0,7})");
if (reg.test(results["dlat"])== false || reg.test(results["dlon"])== false) {
app.alert("Invalid value entered in the Longitude-Latitude text fields.", 0);
}
var longitude = new RegExp("(\-?(180|(1[0-7][0-9]|[0-9]{0,2})\.[0-9]{0,7})");
if (reg.test(results["dlat"])== false || reg.test(results["dlon"])== false) {
app.alert("Invalid value entered in the Longitude-Latitude text fields.", 0);
}
// Evaluate if any of the input fields are empty and alert the user
if ( results["dlat"]=="" ||
results["dlon"]=="" ||
results["dday"]=="" ||
results["dhrs"]=="" ||
results["mins"]=="" ||
results["zone"]=="" ||
results["dmon"]=="" ||
results["year"]=="" ) {
app.alert("Please complete all of the required blanks\n\n\nNote the referenced example: 112305Z Aug 2023", 1)
}
},
// Createt the Dialog Box Display Title
description: {
name: "Military Date Time Group (DTG)",
align_children: "align_left",
width: 150,
height: 200,
elements:
// Set additional instructional static text
[{type: "cluster",
name: "Please fill in all of the required blanks provided:",
align_children: "align_left",
elements: [
// Set the text field for Latitude entry
{ type: "view",
char_width: 11,
align_children: "align_row",
elements: [{ type: "static_text",
name: "Latitude: " },
{ item_id: "dlat",
type: "edit_text",
char_width: 11,
alignment: "align_left",
width: 100,
height: 20
}]
},
// Set the text field for Longitude
{ type: "view",
align_children: "align_row",
elements: [{ type: "static_text",
name: "Longitude: " },
{ item_id: "dlon",
type: "edit_text",
char_width: 11,
alignment: "align_left",
width: 100,
height: 20
}]
},
// Display instructional static text with example format
{ type: "static_text",
name: "Example of required Latitude input: 9.9824245 and Longitude input: 76.5703886",
char_width: 50 },
]
},
// Set the text field for the Day
{ type: "view",
align_children: "align_distribute",
elements: [{ type: "static_text",
name: "Day: " },
{ item_id: "dday",
type: "edit_text",
char_width: 2,
alignment: "align_left",
width: 30,
height: 20
}]
},
// Set the text field for the Hours
{ type: "view",
align_children: "align_distribute",
elements: [{ type: "static_text",
name: "Hours: " },
{ item_id: "dhrs",
type: "edit_text",
char_width: 2,
alignment: "align_left",
width: 30,
height: 20
}]
},
// Set the text field for the Minutes
{ type: "view",
align_children: "align_distribute",
elements: [{ type: "static_text",
name: "Minutes: " },
{ item_id: "mins",
type: "edit_text",
char_width: 2,
alignment: "align_left",
width: 30,
height: 20
}]
},
// Set the text field for the Military Time Zone designator letters A-Z
{ type: "view",
align_children: "align_distribute",
elements: [{ type: "static_text",
name: "Military Timezone: " },
{ item_id: "zone",
type: "edit_text",
char_width: 1,
alignment: "align_left",
width: 40,
height: 20
}]
},
// Set the text field for the Month
{ type: "view",
align_children: "align_distribute",
elements: [{ type: "static_text",
name: "Month: " },
{ item_id: "dmon",
type: "edit_text",
char_width: 3,
alignment: "align_left",
width: 40,
height: 20
}]
},
// Set the text field for the Year
{ type: "view",
align_children: "align_distribute",
elements: [{ type: "static_text",
name: "Year: " },
{ item_id: "year",
type: "edit_text",
char_width: 4,
alignment: "align_left",
width: 40,
height: 20
}]
},
// Set the OK and CANCEL button objects
{ alignment: "align_right",
type: "ok_cancel",
ok_name: "Ok",
cancel_name: "Cancel"
}]
}
};
The function variable is called with a Mouse Up event from the target field with the line below:
//invoke document-level fucntion
(event.target.value == "") ? app.execDialog(dialog2) : this.resetForm(["Text13"]);
NOTE:
You will note that in the dialogue script that I've separated the latitude and longitude in separate fields.
And I am stuck with the regular expressions that I borrowed from https://regexlib.com/ in order to match a pattern of + or - dd.ddddddd for latitude decimal values and a pattern of + or - ddd.ddddddd for longitude decimal values.:
The idea of employing the modal dialogue is to facitlitate the user with the ability to input data quickly and easy but limitting them to only be able to type the specific amount of digits to right or left of the decimal period.
Once the user clicks or press the OK button, all the values that were collected (or stored) through the dialogue box function will be concatenated into a single text string to produce the desired DTG output as :
Final toughts, one other important things that I forgot to clarify in my earlier replies is that Military Timezones designators are from A-Z with the exception of the letter "J" (Juliet Timezone).
Lima (L) is not designated for Military local time .
And the Zulu Military Timezone is confused with a local time of 0 hours (0000 zero hundred) interchangeably with 0000 degrees longitude at the Prime Meridian; that is incorrect.
It simply has no direct relationship with the UTC 0000 offset and the 0000 zero hundred hours (midnight military time) when someone is referring to local time.
But anyhow, Juliet Military Zone is omitted from the 24 longitudes.
When it is employed is to express the observer's local time (wherever that timezone in the world may be) and not Zulu UTC standard time which is based off in Greenwhich , England.
Copy link to clipboard
Copied
The script looks and works great. Is there a way to prevent the user from entering an incorrect format/data? FYSA, My end-state is to minimize the inevitable fatfingering for data collection on SITREPS and Noon reports. Nautical lat/longs (ex 38° 53' 50.9254"N/S; 77° 2' 15.2339E/W) are the most notorious screwups during data entry and make accurately tracking vessels difficult to impossible.
Thank you again for the effort and hard work. It is truly impressive.
Copy link to clipboard
Copied
Yes,
Is there a way to prevent the user from entering an incorrect format/data?
I am still working on it.
The script that I posted needs improvements and it is not a final work.