About the blank, no, it can cost no variable, one can never define it, making it entirely hardcoded i.e. something *like* the attached. (BTW I have to review it, a space is semingly missing, it should be 80 spaces total (obviously) to cover the whole line, but 79 are enough
, the double quotes can be removed if we use \x20<-78 spaces>\x20, which is also easier to look at.
I don't know, the prompt is still only - from an interface viewpoint - "just thrown in".
We have a limited number of "status" lines, the idea is to keep them "in the same place in any case", in "sector view mode:
line 19 is reserved for expansion of hot-keys command and user input
line 20 is additional line for confirm and similar, though mostly a separator between 19 and the following 4 lines
line 21 is either 1st line of hints or empty
line 22 is either 2nd line of hints or load history
line 23 is either 3rd line of hints or save history
line 24 is either 4th line of hints hints or Clipboard status
The current use of lines 19 and 20 as "return" from P[R]ompt is only to avoid overwriting the hints/history, but of course it is only a very temporary storage as it will be overwritten at the next first command.
If I change the [H] hotkey from a two states toggle Hints/History to a three state one, Hints/History/Hic (Human issued commands
), we can have more space (lines 21,22,23 and 24) to hold information from the *whatever* was done in P[R]ompt.
What would be useful? Would this be "enough"? Something else that could be useful?
1) last command line issued
2) last command line with expanded variables
About the param=%1 check, your approach is nice, but unfortunately not complete (not that the current solution is any good), a parameter:
should work in theory
(for those people that use decimal), currently the second works, but not the first.
Validation of user input is tough
Douglas Adams said:
“A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools.”
P.S. BTW the lines:
echo -e -P:2100 Sectedit.g4b - Current sector:$[0x03](md)$[0x03]%mdoffset%+1 $Memory address:$[0x03]%target%
echo -P:2200 -v
were put there only to make the users aware that they are inside a pseudo-prompt, maybe they can be both removed, the position of sector view can be easily seen by going back and the grub4dos version is not particularly relevant.
Is the cyano "grub command:" enough to make the screen recognizable from a "plain, direct" grub> one?
P.P.S.: about the check for dd if= and of=, at the end of the day this three liner seems to work fine (let's say good enough):
#fileorbl2.g4b - batch to check if a parameter is a (valid) file or a device blocklist
#for dd use, i.e. full path (<device>)[/<path>/]/filename.ext or (<device>)<start>+<numblocks>
if "%thiswhat:~0,1%"=="/" set thiswhat=%@root%%%thiswhat%
if not "%thiswhat:~0,1%"=="(" set thiswhat=%@root%/%thiswhat%
if exist %thiswhat% echo %thiswhat%, OK. || echo %thiswhat%, NO good.
it adds device (root) if it is missing and root and the forward slash if it is missing. Of course it cannot cure stupidity but it should help avoiding some errors on load and save dialogs in sectedit.g4b.