topbanner_forum
  *

avatar image

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  • Friday May 31, 2024, 12:38 pm
  • Proudly celebrating 15+ years online.
  • Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.
  • donate

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - ConstanceJill [ switch to compact view ]

Pages: [1] 2 3 4 5 6 ... 10next
1
Yep, looks like points 1 and 2 are fixed indeed, thanks! :)
I'll let you know if I find anything else.

2
Thanks! :)

So I extracted 2.1.0 build 70 BETA and tried running a few commands on my work computer, but I ran into a an error with a few of them.

For example, I have a button with the following settings :

Image File: <appdir>icons\Ping.png
Application: ping.exe
Application Arguments :-t <var>
Start in:
Button Caption: Ping -t
Command Window : Skip (Direct Launch)
Ignore : Variable Whitespace
When trying to run that command, I'm met with the following error message:
Launch cancelled. Application file listed bellow is missing.

ping.exe

Same problem with buttons that I set to direct launch mstsc.exe, explorer.exe or mmc.exe

From what I gathered, it would seem that, when using "Direct Launch" only, when the full path to the application is not specified, this version of the program tries to check if it finds the program in the PATH, but fails to find it.
However, it does find and launch successfully some third party executables that I've placed in other folders, which I added to my system PATH, without having their paths spelled out in the button settings.
I suspect that it probably has to do with the PATH relying on the %SystemRoot% environment variable for executables that ship with Windows (?)

Replacing the setting in the button with "%systemroot%\system32\ping.exe" also does not fix the problem, I have to put "C:\Windows" in place of "%systemroot%".


Another minor annoyance that I noticed is that, after editing a button, the contents of the Variable field is emptied.

3
All right :)

I also noticed one other issue: I have this RAM drive program called OSFMount installed; and I drag and dropped its shortcut from my start menu to CRAP.

It requires admin rights to be ran, so Windows' User Account Control window usually pops up when starting it —and it did so indeed back when I was launching it from version 2.1.0 build 60 beta— however, in build 68 beta, CRAP only gives with an error message « L'opération demandée nécessite une élévation » (translated back to english: « The requested operation requires an elevation »). The UAC window does not appear and the program isn't ran.

4
Hello there.

I unzipped version 2.1.0 build 68 beta over my existing install on my home computer (which previously had build 60 beta) and got a few new bugs when using it to launch some (but not all) programs:

1 : It appears that, if the "Start in" field has the path within double quotes (for example, "D:\steam" ) then when clicking the button, instead of the program being started, I get the following error message:
Error while launching application.
Caractères non conformes dans le chemin d'accès.

That last line would translate back to english into something akin to "invalid characters in path"

I don't have the issue when making a new layout so I guess it's likely to only be an issue for the small niche of people who tried a previous beta where the Start in field was already a thing, or who would perhaps manually create such a button, but I feel that either the error message should be made more explicit, or perhaps the program should either automatically remove or ignore double quotes in that field — after testing, I can confirm they're not needed even if the program must be started in a folder that has spaces.

2 : I had a button with the following parameters:
Image file: <sysroot>System32\conhost.exe;0
Application: <sysroot>System32\conhost.exe
Start in: %userprofile%\desktop
Button Caption:\nCMD
Command Window: Skip
Ignore: Variable Text

With build 60 beta the program did run (albeit it started the program in the same folder where the shortcut to launch CRAP pointed it to start in, instead of the one I had specified in the button's properties), but now it gives me a different error instead (see attachment, the line in french would translate to "invalid folder name").
Removing the contents of the "Start in" field from the button, or making sure it doesn't use environment variables with "%", allows it to work again.

Another little thing: I noticed that, if the button caption starts with "\n" to avoid having the text appear too close to the icon, the "\n" also is displayed in the tooltip while hovering the button. While it's more accurate to have it show, I can't help but think it probably shouldn't be showing in the tooltip. However, it would probably be even better if the user could, under the global button properties, set a minimum spacing between the icon and text, so that there would be less need for "\n" in captions.

5
Thanks!
I'll be on vacation for 2 weeks so I'll probably be using CRAP a lot less during that time as I mostly use it for work, but I'll let you know as soon as possible.

6
I can't tell for sure but I think so far I mostly had it happen with the ping command, which happens to be the first in my layout (in case that's relevant).

7
Hey there,

I've been using 2.1.0 beta 67 today and I've run into a kinda new issue.

With previous versions it already happened from time to time that, while launching a command with a button, I'd get the attached error message. It was not a very common occurrence and the command ran anyway with no other issue, so I didn't mind much.
What's new with this latest beta is that, after running into that error, now I can't seem to interact with the Variable field any more. I can open the drop-down list (which appears to be empty while it shouldn't be) but can't get the blinking cursor to appear inside the field itself, or select the current value by double clicking it, or even replace it by selecting a favorite… seems the only way out is to exit CRAP and restart it.

8
I'm wondering if having it hide as long as no button uses the variable may be confusing for new users that didn't read about the feature first, especially if it's hidden when they start a new layout (which by default would be empty), or if they just start by making one such button and then the field disappears.

Maybe having it just be a toggleable option for each layout would keep it more simple (also when it comes to maintaining the code, even though I guess that's not for me to worry about).

9
Well I'm sure yet if that's a good idea, but I've been thinking, perhaps it would be nice to have a layout-related option that would allow to hide the Variable field and Favorites menu, in case someone intends to use that layout specifically for shortcut type links that do not require any input?

10
All right, I've tested it a little bit and indeed the 3 issues I had posted about in post #133 seem to be fixed.

I've noticed however that in the "Start in" field, it appears that CRAP puts the path it imported between double quotes, and that seems to not work exactly as expected as, for example :
- Diablo 2 Lord of Destruction, when connecting to Battle.net, creates a BnetLog.txt file in the folder where it is started in.
If it is started from a button in CRAP where the "Start in" field has double quotes around it, then that file is created in the same folder where CRAP itself was started in
- The Dark Mod v2.12 x64 (it's a free game, get it from https://www.thedarkmod.com/downloads/ :) ) exhibits a similar behaviour, also creating its Darkmod.log file in the same folder where CRAP was started in
- Thief Gold, if its install.cfg file (that file basically tells it where to look for its resources) contains relative paths such as ".\", which is likely to be the case if it was patched up TFix (which is very much THE recommended unofficial patch package), will fail to run when started from such a button.

In all those examples, removing the double quotes around the contents of the "Start in" field from the buttons fixed the issues.

Now I didn't try to install those games in folders that had spaces in them, so I'm not sure if the double quotes would be required then or would still cause issues.

11
Thanks, I'll download and test it ASAP :)

[…]
Note: Also in this version...I don't know if I should keep/remove but atm if the control key is pressed when dropping it will add all without the add dialogs...should I keep or remove?
Sounds neat, if the default settings it adds the button with are all right then I see no reason to remove it.

12
Hello there :)

Today I've tested (on my home computer, running Windows 11 v23H2) adding buttons using the shortcut drag and drop feature, and I've encountered a few issues, some of which seem to be related to the handling of lower/uppercase.

1 - when adding a single button, if the ".exe" part of the icon's name happens to not be entirely in lowercase, then in the main window, the button's icon and caption do not appear.
The button itself can still be highlighted when placing the mouse cursor at its position, the tooltip shows up and the associated program can still be launched.
Changing the button's properties to have the ".exe" in the icon's name be in lower case fixes that issue

2 - when dragging several shortcuts to the main window in order to create the corresponding buttons.
If a single one of those shortcuts has the ".EXE" part of target program's filename written uppercase, then CRAP will open the "Adding New Button" dialogue for each shortcut, until the user confirms the "Add" button for that one shortcut with the uppercase ".EXE", at which point CRAP will basically abort processing the queue: there will be no further window to add the next shortcuts even if more were selected, and the buttons for which the settings were already input will not be added to the layout.

3 - This one isn't related to uppercase vs lowercase file names, but to how some games themselves behave.
A normal Windows shortcut has a "start in" field, which, from my understanding, basically sets the "current folder" before starting the program. This field doesn't appear to exist for CRAP buttons, and so for some programs that need it to be set, they may either fail to run, or try to look for and/or write some files in the wrong place.

13
Cool, I'll download and test it a bit later.

From your animated demo though it looks like it doesn't have "Ignore variable text" checked by default when drag-and-dropping a shortcut, which it probably should.

14
I guess it would be logical to do so indeed.

15
Your current proposal for the message seems self explanatory enough to me :)

16
I think having the contents of  "Application Arguments (optional)" defaulting to <var> (with the text being visible in the field), and adding the validation/warning at the time of saving the button in case the user removed <var> from there without checking "Ignore Variable Text" would make more sense.

17
Thanks I will fix to where if arguments is left blank in the button properties that the variable provided that ignore variable text is not checked will work for the arguments. If you specify arguments then obviously use <var> to where you want the variable to be. Does that sound like the proper way you would expect?
If I understand it right, provided that both the following conditions are met :
1 - "Ignore Variable Text" checkbox is not checked
2 - nothing is specified in the "Application Arguments (optional)" field
then CRAP would run the command with the contents of <var> as its only argument

Sounds fair enough.

Perhaps we may even add a validation such that, before a button can be saved, if the following conditions are all met :
- "Skip Command Window" is checked
- "Ignore Variable Text" is not checked
- <var> is not found anywhere within the arguments
then the program shall issue a warning?

Or maybe have the contents of "Application Arguments (optional)" default to "<var>" as long as "Ignore Variable Text" is not checked?

18
Hey there,

I've imported my work layout, settings and icons into a folder where I unzipped the beta version, which seemed to work fine as far as the import goes.
Favorites menu is fine too :)

Then I tested removing the start command on a few of my GUI driven apps and enabling the "Skip Command Window" option instead, moving all the parameters (when applicable) from the prefix towards the "Application Arguments" field, and indeed it launches the program with no unnecessary CMD window, which is nice :)

I did notice however that, for such buttons where the "Skip Command Window" option is enabled, if the following conditions are all met :
1 - I don't include the <var> parameter anywhere in the "Application Arguments (optional)" field
2 - the "Ignore Variable Text" checkbox is not checked
3 - there is some text in the "Variable" field of the main window

then, when the mouse cursor is over such a button, both the command preview in the status bar and the "Application Arguments:" line within the tooltip look as if the contents of Variable would be included, between the Application and its other arguments (if any are specified), yet the contents of the Variable is actually not included when clicking the button to run the command.

Now obviously I shouldn't forget to include the <var> in the arguments at the position where it's needed, but there still is an inconsistency between what the preview says and what the program does.

19
Download worked, thanks, I'll give it a try a bit later :)

20
I'm getting a 404 when trying the link.

21
Sorry, I'm not quite sure what that means / what it looks like, and the search results I get seem to be more about the code to implement one…
I don't really mind the current text input fields by the way, so if it's too much work to just have their background color changed by the theme, please don't feel pressured to change that.

22
Should be fine I guess. I'd prefer the text contents (typically a hostname) to be visible before selecting the favourite, but I suppose I could always include it in the description myself.

23
Hmm to elaborate on the topic of the command line window, what I've been experiencing does not seem to me like an issue with the option to keep it open or not after a command ended, but rather, it's pretty much like the normal behavior of batch files: they just don't go to the next line until the current command has completed, which in the case of most executable means, until their process has ended.

And so if you use cmd.exe to run a GUI mode program such as the RDP client, Notepad, Firefox… then that CMD window just stays there until you close that GUI program — or manually close the cmd window itself.
The solution to that issue would be, IMHO, to have CRAP run the command which the button is set for "directly", instead of calling cmd.

24
OK, it does seem better especially since the taskbar is dark too :)
Would be nice if the text fields could have a dark background (and probably some lighter shade of gray text for a good contrast) too :D

25
Then I removed some themes (like black for one)
Aww, that's the one I was using on my work computer lately :(
BTW is it possible for the user to make custom themes, or are we restricted to usng the ones that the program ships with?

Pages: [1] 2 3 4 5 6 ... 10next