Best practice to determine the codepage of an unkown file? (with Progress-4GL Openedeg) - openedge

What is the best way to identify the codepage of a file?
I hoped i can use DetectInputCodepage but i dont know how to implement it with progress.

I don't know what led you down that rabbit hole - the link you provided led to outdated documentation for Internet Explorer.
However. This problem is non trivial. See https://community.progress.com/s/article/000057930
Also
How can I detect the encoding/codepage of a text file?
Based on the answer above (on Stackoverflow) you can download the mentioned Nu-package and extract the dll (using any zip-tool).
Add the ude.dll-file to your assemblies and then you can do like this (error checking etc missing in this example):
USING Ude.*.
USING System.IO.*.
DEFINE VARIABLE fs AS FileStream NO-UNDO.
DEFINE VARIABLE ude AS CharsetDetector NO-UNDO.
fs = NEW FileStream( "c:/temp/test.txt", FileMode:Open).
ude = NEW CharsetDetector().
ude:Feed(fs).
ude:DataEnd().
IF ude:Charset <> ? THEN
MESSAGE SUBSTITUTE("Charset &1, confidence &2", ude:Charset, ude:Confidence) VIEW-AS ALERT-BOX.
ELSE
MESSAGE "Failed" VIEW-AS ALERT-BOX.
fs:Close().
DELETE OBJECT fs.
DELETE OBJECT ude.

Related

How to find a file with python with Ã

im working on a mtg auto sorter and some of the cards have interesting names that python seems to not want to find. i am looking for a file (that i know i have in the right spot) called 8_JÃtun_Grunt.png. using this...
for card_name in card_names:
# Fetch the image - name can be found based on the card's information
card_info['name'] = card_name
img_name = '%s/card_img/png/%s/%s_%s.png' % (Config.data_dir, card_info['set'],
card_info['collector_number'],
fetch_data.get_valid_filename(card_info['name']))
card_img = cv2.imread(img_name)
# If the image doesn't exist, download it from the URL
if card_img is None:
fetch_data.fetch_card_image(card_info,
out_dir='%s/card_img/png/%s' % (Config.data_dir, card_info['set']))
card_img = cv2.imread(img_name)
if card_img is None:
print('WARNING: card %s is not found!' % img_name)
the error i get is so
error from cmd
this leads me to think that it cant recognize the file name but im reading it from a database that i cant change. any ideas.
I wouldn't be surprised if OpenCV couldn't handle filepaths with unicode caracters.
you could try to add the code from the answer of this SO question

Progress 4GL: Regarding OUTPUT TO statement

What happens when I don't give directory path? Where the file is exported?
DEFINE VARIABLE cPath AS CHARACTER NO-UNDO.
cPath = STRING(MTIME) + "_user.out".
OUTPUT TO VALUE (cPath).
MESSAGE "In side a file".
OUTPUT CLOSE.
The file is exported to your client's working directory. That is typically the directory where you've been in when you have started the client process (_progres, prowin, prowin32).
You can use FILE-INFO to find out:
DEFINE VARIABLE cPath AS CHARACTER NO-UNDO.
cPath = STRING(MTIME) + "_user.out".
OUTPUT TO VALUE (cPath).
MESSAGE "In side a file".
OUTPUT CLOSE.
file-info:file-name = "./" + cPath.
message cPath file-info:full-pathname.
By the way - if you are hoping that using MTIME() to prefix the file name is going to result in a unique file name then you may be disappointed. Multiple processes running at the same time could have collisions. Or you may have old stale files left over from crashed sessions.

Reading in a binary grid file in Fortran 90

I'm having issues when trying to read in a binary file I've previously written into another program. I have been able to open it and read it to an array with out compilation errors, however, the array is not populated (all 0's). Any suggestions or thoughts would be great. Here is the open/read statement I'm using:
allocate(dummy(imax,jmax))
open(unit=io, file=trim(input), form='binary', access='stream', &
iostat=ioer, status='old', action='READWRITE')
if(ioer/=0) then
print*, 'Cannot open file'
else
print*,'success opening file'
end if
read(unit=io, fmt=*, iostat=ioer) dummy
j=0
k=0
size: do j=1, imax
do k=1, jmax
if(dummy(j,k) > 0.) print*,dummy(j,k)
end do
end do size
Please let me know if you need more info.
Here is how the file is originally written:
out_file = trim(output_dir)//'SEVIRI_FRP_.08deg_'//trim(season)//'.bin'
print*, out_file
print*, i_max,' i_max,',j_max,' j_max'
open (io, file = out_file, access = 'direct', status = 'replace', recl = i_max*j_max*4)
write(io, rec = 1) sev_frp
write(io, rec = 2) count_sev_frp
write(io, rec = 3) sum_sev_frp
check: do n=1, i_max
inna: do m=1, j_max
!if (sev_frp(n,m) > 0) print*, count_sev_frp(n,m)
end do inna
end do check
print*,'n-',n,'m-',m
close(io)
First of all the form takes two possible values as far as I know: "FORMATTED" or "UNFORMATTED".
Second, to read, you should use a open that is symmetric to the open statement that you used to write the file, Unless you know exactely what you are doing. I suggest that for reading, you open with:
open(unit=io, file=trim(input), access='direct', &
iostat=ioer, status='old', action='READ', recl = i_max*j_max*4)
That corresponds to the open statement that you used to save the file.
As innoSPG says, you have a mismatch in the way the file is written and how it is read.
An external file may be connected with one of three access methods: sequential; direct; stream. Further, a connection may be formatted or unformatted.
When the file is opened for writing it uses the direct access method with unformatted records. The records are unformatted because this is the default (in the abscence of the form= specifier).
When you open the file for reading you use the non-standard extension of form="binary" and stream access. There is possibly nothing wrong with this, but it does require care.
However, with the read statements you are using formatted (list-directed) input. This will not be allowed.
The way suggested in the previous answer, of using a similar access method and record length will require a further change to the code. [You'll also need to set the value of the record length somehow.]
Not only will you need to remove the format, to match the unformatted records written, but you'll want to use the rec= specifier to access the records of the file.
Finally, if you are using the iostat= specifier you really should check the resulting value.

PROGRESS - Validating a user-input file output path

I've written some PROGRESS code that outputs some data to a user defined file. The data itself isn't important, the output process works fine. It's basically
DEFINE VARIABLE filePath.
UPDATE filePath /*User types in something like C:\UserAccount\New.txt */
OUTPUT TO (VALUE) filePath.
Which works fine, a txt file is created in the input directory. My question is:
Does progress have any functionality that would allow me to check if an input
file path is valid? (Specifically, if the user has input a valid directory, and if they have permission to create a file in the directory they've chosen)
Any input or feedback would be appreciated.
FILE-INFO
Using the system handle FILE-INFO gives you a lot of information. It also works on directories.
FILE-INFO:FILE-NAME = "c:\temp\test.p".
DISPLAY
FILE-INFO:FILE-NAME
FILE-INFO:FILE-CREATE-DATE
FILE-INFO:FILE-MOD-DATE
FILE-INFO:FILE-INFO
FILE-INFO:FILE-MOD-TIME
FILE-INFO:FILE-SIZE
FILE-NAME:FILE-TYPE
FILE-INFO:FULL-PATHNAME
WITH FRAME f1 1 COLUMN SIDE-LABELS.
A simple check for existing directory with write rights could be something like:
FUNCTION dirOK RETURNS LOGICAL (INPUT pcDir AS CHARACTER):
FILE-INFO:FILE-NAME = pcDir.
IF INDEX(FILE-INFO:FILE-TYPE, "D") > 0
AND INDEX(FILE-INFO:FILE-TYPE, "W") > 0 THEN
RETURN TRUE.
ELSE
RETURN FALSE.
END FUNCTION.
FILE-NAME:FILE-TYPE will start with a D for directories and a F for plain files. It also includes information about reading and writing rights. Check the help for more info. If the file doesn't exist basically all attributes except FILE-NAME will be empty or unknown (?).
Edit: it seems that FILE-TYPE returns W in some cases even if there's no actual writing rights in that directory so I you might need to handle this through error processing instead
ERROR PROCESSING
OUTPUT TO VALUE("f:\personal\test.txt").
PUT UNFORMATTED "Test" SKIP.
OUTPUT CLOSE.
CATCH eAnyError AS Progress.Lang.ERROR:
/* Here you could check for specifically error no 98 indicating a problem opening the file */
MESSAGE
"Error message and number retrieved from error object..."
eAnyError:GetMessage(1)
eAnyError:GetMessageNum(1) VIEW-AS ALERT-BOX BUTTONS OK.
END CATCH.
FINALLY:
END FINALLY.
SEARCH
When checking for a single file the SEARCH command will work. If the file exists it returns the complete path. It does however not work on directory, only files. If you SEARCH without complete path e g SEARCH("test.p") the command will search through the directories set in the PROPATH environment variable and return the first matching entry with complete path. If there's no match it will return unknown value (?).
Syntax:
IF SEARCH("c:\temp\test.p") = ? THEN
MESSAGE "No such file" VIEW-AS ALERT-BOX ERROR.
ELSE
MESSAGE "OK" VIEW-AS ALERT-BOX INFORMATION.
SYSTEM-DIALOG GET-FILE character-field has an option MUST-EXIST if you want to use a dailogue to get filename/dir from user. Example from manual
DEFINE VARIABLE procname AS CHARACTER NO-UNDO.
DEFINE VARIABLE OKpressed AS LOGICAL INITIAL TRUE.
Main:
REPEAT:
SYSTEM-DIALOG GET-FILE procname
TITLE "Choose Procedure to Run ..."
FILTERS "Source Files (*.p)" "*.p",
"R-code Files (*.r)" "*.r"
MUST-EXIST
USE-FILENAME
UPDATE OKpressed.
IF OKpressed = TRUE THEN
RUN VALUE(procname).
ELSE
LEAVE Main.
END.

BizTalk SourceFileName becomes dehydrated

I'm trying to use a custom filename since i need to create two files (a backupfile) so i followed the following tutorial to create filename Here
now when i test this with DELCUS%MessageID%.txt everything works fine but when i change it to DELCUS%SourceFileName%.txt the interface becomes permanently dehydrated.
the only thing i do for the filename is this
fileName = "ContExt" + System.DateTime.Now.ToString();
Message_send_Belspeed_BeautDay_ContExt(FILE.ReceivedFileName) =
fileName;
is there any reason why the use of SourceFileName would cause this to dehydrate?
Found the issue.
after a while the interface did crash and the filename looks like
DELCUS2012 10:50:40.txt
having : in a filename is not good.
This is just a standard windows file naming limitation, you can't name your file using any of these characters "\ / : * ? " < > |". So obviously your instances are going to get stuck!!

Resources