wxFileDialog filename textbox appears as clipped - textbox

I display an Open File dialog using the following code:
wxFileDialog fileDialog(
this,
wxEmptyString,
"E:\\Testfiles",
"SOME_TEST_FILE_WITH_LONG_NAME.txt",
"TXT files (*.txt)|*.txt",
wxFD_OPEN | wxFD_FILE_MUST_EXIST | wxFD_CHANGE_DIR);
if (fileDialog.ShowModal() == wxID_OK)
{
// do something with the file
}
Notice that I set the default filename to a long string (about 10 or more characters).
When the file dialog is displayed, the filename looks clipped.
But on inspection, it's not really clipped.
More like the starting point of the text is placed too much to the left.
When you place the cursor on the textbox, and scroll to the left, you get the complete filename.
Also, when you switch to a different window then return to the file dialog, it corrects itself and displays the complete filename.
This isn't really affecting the functionality of the file dialog.
This is more of an aesthetic issue.
But if there's a reason for this behavior or if there's a solution, I would like to know.
Thanks!
I'm using:
wxWidgets 3.1.0
Windows 10 Home 64-bit
UPDATE (2017/03/20):
I opened a ticket at wxTrac for this bug.
You can check it here:
http://trac.wxwidgets.org/ticket/17824.

This looks like a bug in wxWidgets, please try to reproduce it in the dialogs sample by making minimal changes to the wxFileDialog call which is already present there and open a ticket on wxTrac with the patch allowing to see the problem, so that someone could debug it.

As a temporary workaround (while an official resolution from wxWidgets is not yet available), calling CenterOnParent() after constructing the file dialog properly "scrolls" the filename so that it won't appear as "clipped".
wxFileDialog fileDialog(
this,
wxEmptyString,
"E:\\Testfiles",
"SOME_TEST_FILE_WITH_LONG_NAME.txt",
"TXT files (*.txt)|*.txt",
wxFD_OPEN | wxFD_FILE_MUST_EXIST | wxFD_CHANGE_DIR);
// fixes the clipped filename
fileDialog.CenterOnParent();
if (fileDialog.ShowModal() == wxID_OK)
{
// do something with the file
}

Related

In Visual Studio Code Ctrl+V is not working

In Visual Studio Code Ctrl+V is not working on editor.
However from the command palette Ctrl+Shift+V is working.
I´ve had this problem when I enabled the "VIM" plugin for VSCode.
After uninstalling it, the problem was fixed.
Open the keyboard shortcuts preferences by pressing CTRL + SHIFT + P and search for open keyboard shortcuts file.
Then, search for the editor.action.clipboardPasteAction property. In your case, it might be CTRL+SHIFT+V. Try changing it to Ctrl + V. Like so:
Solution as of 2022
You could also CTRL + SHIFT + P and search for open keyboard shortcuts (JSON) and paste the following:
// Place your key bindings in this file to override the defaults
[
{
"key": "ctrl+v",
"command": "-workbench.action.terminal.sendSequence",
"when": "terminalFocus && !accessibilityModeEnabled && terminalShellType == 'pwsh'"
},
{
"key": "ctrl+k",
"command": "workbench.action.terminal.clear"
}
]
#WebD'is answer is very helpful and I have upvoted it. But my comment focused on whether there was a conflicting binding for CTRL-V and how to find it. You can literally type "Ctrl+V" (note the "plus+" sign, not a hyphen) and it will find all keybindings that use that binding in whole or part. I suggest that there must be a something else also bound to CTRL-V.
Since this original answer, vscode introduced another way to see what other commands might be bound to given keystrokes. With the Gear/Keyboard Shortcuts file open click on the little keyboardy icon to the right (or Alt+K with this file open) and it will indicate Recording Keys next to it. Now you can literally press Ctrl+V (or whichever keybinding you are interested in) and those corresponding commands, if any, that use that keybinding will be filtered up.
Remember to disable the Recording Keys functionality by clicking the keyboardy icon if you want to go back to regular searching in the Keyboard Shortcuts file.
I have the same problem: can't CTRL+X, CTRL+C, CTRL+V on VSCode editor.
I uninstall the Vim extension and the problem is fixed.
If you install the vim extension for visual studio code and find that ctrl + x, ctrl + v .. or other shortcuts stopped working, this is because they are overwritten by extension.vim_
If you prefer to get those shortcuts back go to keyboard shortcuts (ctrl + shift + p, then search for open keyboard shortcuts file).
Search for extension.vim_ and check too see if any shortcuts are
assigned to your key combination like ctrl + v. Remove it (right click, delete).
Also check for any other conflict by searching the file.
Save the file, it should work now.
For future searchers who do not have Vim (or any other extension) installed which is causing the issue, and who might have verified that their keyboard bindings are correct....
I have the Salesforce Extension Pack installed and had right-clicked on a file and run SFDX: Deploy Source to Org. The deployment had errors, so in the Panel area (which I have at the bottom of my screen) [see image] I had clicked on both the OUTPUT and PROBLEMS tabs, which shifted focus away from my PowerShell TERMINAL tab.
My Ctrl-V issue was when I was trying to correct my Apex code in the EDITOR pane. Ctrl-V was not pasting the code I had just Cut or Copied (but right-clicking and choosing Paste was working).
I ultimately discovered, when I changed my Panel focus back to my PowerShell TERMINAL tab, that ALL of the Ctrl-V pasting I had attempted had shown up after my PowerShell prompt! ["circled" in blue in image]
tl;dr
Make sure your pasted text did not show up in your TERMINAL - even if it is not in focus or even if your cursor is in another Panel tab or in the EDITOR.
From File > Performance > Keyboard Shortcuts > search paste > just try to remove or rest some keybinding with right click on paste or default:paste
If you have the Vim extension installed, you may set the vim.useSystemClipboard in the vim extension setting to true. Then you can paste the content from the clipboard by simply pressing p in the NORMAL mode, or use Ctrl+V in the INSERT mode.
This problem happened to me after I left VSC update itself (currently 1.53.0). It had been converted to Shift-Insert.
Go to File->Preferences->Keyboard shortcuts. Find the editor.action.clipboardPasteAction and double click it, then type Ctrl+V.
+1 for this - in case this helps anyone:
In my case it was only happening in the Thunder Client extension's text fields.
The culprit for me was the Indent on Paste extension (I'm on a Mac, so it was cmd+v instead of ctrl+v - but it fires the same event in VS Code).
I've left issue comments on the Thunder Client and Indent on Paste repos respectively, should anyone wish to add to those.
Look if and remove any VS Code extension :
for example - "Awesome Emacs Keymap" in my case, or any other keymaps installed.
i.e. : FILE/Preferences>/extensions and then look if any special keymap was installed
Modify the setting of vscode:
Settings - input:vim ctrl key - unselect: Enale some vim ctrl key commands that override otherwise common operations, like ctrl + c
go to extensions search Emacs keymap and uninstall it
There should something conflicting to your any previous keyboard shortcut
like in my case for Change All Occurrence: (Ctrl-C + Ctrl-A), vs code, confused with
Ctrl-C for a copy shortcut to this : (Ctrl-C + Ctrl-A), so I change this to (Shift-C + Shift-A), My Issue resolved.
Go to File>Preference>keyboard Shortcuts
Then Check for Copy and paste and enter the Ctrl+C and Ctrl+v shortcuts
Happy Coding ;)
None of the issues above solved this for me. I had a key binding Ctrl+C Ctrl+L. So when I pressed Ctrl+C it was in a state where it was waiting for the next key to be pressed and wouldn't do anything.
This showed up in the toolbar like so (an example):
This didn't come up in the list of keybindings when searching for Ctrl+C. So I found it be looking through the list.
Remove all cmd+v or in windows ctrl+v associated keybindings.
For me the solution was going through my extensions and disabling them one by one to find the culprit.
I had 'Paste and Indent' enabled which was messing up copying and pasting.
Just had to disable it and reload vs code.
Open Settings > keyboard shortcuts
Search for Ctrl + c
Delete the mapping for vim.
i have same problem
step:1
ctrl+shift+p
step:2 find
Open keyboard shortcuts
step:3
find paste
then you can see
editor.action.cliboardPasteAction
right click then changekeybinding if key wrong
or remove key if u found two same line(editor.action.cliboardPasteAction)
in my case is 2nd one(so i removed)
In some cases, if you use remote ssh connects to a remote server and code there, ctrl + V may not be useful because that your remote server has a high balance, you can try to uninstall some useless plugins in that remote server then reload vscode.
I have disabled all extensions, and VS Code hangs for a few seconds whenever I try to paste something. This occurs with Ctrl+V, Shift+Ins and also with right click + Paste.
It hangs, and then nothing happens.
[UPDATE]
I simply reinstalled it, and that solved the issue for me.
In my case just the relaunch of VSCode solved the issue. My key bindings were fine.
"Paste JSON as Code" was my offender, as well as a few other ones. I got a little extension happy there for a bit.
Its easy don't worry, you need to search using ctrl+shift+p and find Prefernces: Open Keyboard Shortcuts(JSON) and add this dict
// Place your key bindings in this file to override the defaults
[
{
"key": "ctrl+c",
"command": "editor.action.clipboardCopyAction",
"when": "textInputFocus"
}
]
I thins it's very helpfull good luck :)

nicEdit Uploading Locally - Issues with nicUpload

If anyone has managed to get locally uploading images I'd be mightily appreciative of some help.
I've downloaded the latest version of nicEdit along with the nicUpload plug in (from nicedit.com - Version 0.9 r24 released June 7th, 2012).
I've also downloaded nicUpload.php from http://svn.nicedit.com//trunk/nicUpload/php/nicUpload.php
NicUpload.php - I've set NICUPLOAD_PATH and NICUPLOAD_URI both to 'images' which is the subfolder of where nicupload.php and nicEdit.js are located.
NicEdit.js - I've added the following to line 271:-
uploadURI : 'nicUpload.php?id=123',
I've given it an ID otherwise it was failing with an invalid ID code. But the ?id=123 isn't meant to be there. I've also set the iconsPath accordingly.
Line 1370 I've switched this:-
nicURI : 'http://api.imgur.com/2/upload.json',
for this:-
nicURI : 'http://www.mydomain.com/nicedit/nicUpload.php',
But I'm still getting "Failed to upload image". I've searched and searched and searched for answers to this and I'm getting close to having spent two days tinkering with it.
With a few debugging displays I can see that it's failing on line 46 of nicUpload.php where it says:-
$file = $_FILES['nicImage'];
$image = $file['tmp_name'];
$max_upload_size = ini_max_upload_size();
if(!$file) {...
That last IF is true and that's where it exits with the error.
Appreciate anyone being able to help.
The nicUpload.php script file laying around sucks and I don't even understand how it could work.
NicEditor uses imgur as the default image upload service. The source code follows the API format described here: http://api.imgur.com/resources_anon#upload
My suggestion would be to implement the API request and response defined there.
I did not use the niceedit upload function to do what you want. I managed to add a button to the link and img dropdown menu. The button opens a file manager window where you also can upload. I managed to put then de url of the image or document into the nicedit drop down img or url window. That is how I solved the problem.

ABCPDF Font Printing Layout - Machine Dependent

I am using ABCPDF to print a PDF file to a local printer via EMF file. I've based this very closely on ABC PDF's sample "ABCPDFView" project. My application worked fine on my Windows 7 and Windows XP dev boxes, but when I moved to a Windows 2003 test box, simple embedded fonts (like Times New Roman 12) rendered completely wrong (wrong spot, and short and squat, almost like the DPI's were crazily wrong).
Note that I've hardcoded the DPI to 240 here b/c I'm using a weird mainframe print driver that forces 240x240. I can discount that driver as the culprit as, if I save the EMF file locally during print, it shows the same layout problems. If I render to PNG or TIFF files, this looks just fine on all my servers using this same code (put .png in place of .emf). Finally, if I use the ABCPDFView project to manually add in a random text box to my PDF, that text also renders wrong in the EMF file. (Side note, if I print the PDF using Acrobat, the text renders just fine)
Update: I left out a useful point for anyone else having this problem. I can work around the problem by setting RenderTextAsText to "0" (see code below). This forces ABCPDF to render the text as polygons and makes the problem go away. This isn't a great solution though, as it greatly increases the size of my EMF files, and those polygons don't render nearly as cleanly in my final print document.
Anyone have any thoughts on the causes of this weird font problem?
private void DoPrintPage(object sender, PrintPageEventArgs e)
{
using (Graphics g = e.Graphics)
{
//... omitted code to determine the rect, used straight from ABC PDF sample
mDoc.Rendering.DotsPerInch = 240 ;
mDoc.Rendering.ColorSpace = "RGB";
mDoc.Rendering.BitsPerChannel = 8;
mDoc.SetInfo(0, "RenderTextAsText", "0");//the magic is right here
byte[] theData = mDoc.Rendering.GetData(".emf");
using (MemoryStream theStream = new MemoryStream(theData))
{
using (Metafile theEMF = new Metafile(theStream))
{
g.DrawImage(theEMF, theRect);
}
}
//... omitted code to move to the next page
}
Try upgrading to the new version of abcpdf 8, it has its own rendering engine based on Gecko and so you can bypass issues like this when abcpdf is using the inbuilt server version of IE for rendering.
I was originally RDPing in with 1920x1080 resolution, by switching to 1024x768 res for RDP, the problem went away. My main program runs as a service, and starting this service from an RDP session w/ 1024x768 fixes it.
I have an email out w/ ABC PDF to see if they can explain this and offer a more elegant solution, but for now this works.
Please note that this is ABC PDF 7, I have no idea if this issue applies to other versions.
Update: ABC PDF support confirmed that its possible the service is caching the display resolution from the person that started the process. They confirmed that they've seen some other weird issues with Remote Desktop and encouraged me to use this 1024x768 workaround and/or start the service remotely.

Use WatiN for automation upload file on the website

I need upload file on the website.
But Have a problem, i can't choose file automatic in code. Always browser show me choose file window.
What wrong in my code?
IE ie = new IE("https://www.xxxx.com/WFrmlogin.aspx");
FileUploadDialogHandler uploadHandler = new FileUploadDialogHandler(#"D:\065-6405_URGENT.xls");
ie.WaitForComplete();
ie.TextField(Find.ById("txtUser")).TypeText("login");
ie.TextField(Find.ById("txtPassWord")).TypeText("***");
ie.Button(Find.ById("btnok")).Click();
ie.WaitForComplete();
ie.GoTo("https://www.orientspareparts.com/inq/WFrmUpOption.aspx");
ie.WaitForComplete();
ie.DialogWatcher.Clear();
ie.AddDialogHandler(uploadHandler);
// This code show choose file dialog
ie.FileUpload(Find.ById("FilUpload")).ClickNoWait();
ie.Button(Find.ById("butUpload")).Click();
ie.WaitForComplete();
I had the same problem. I'm using a GMail-like upload process, so I wanted to test actual use-cases. Just setting the Text property on my hidden file input wasn't an option.
I ended up using SendKeys to type the path to my file, then sent "{ENTER}" to submit the dialog.
SetForegroundWindow(browser.hWnd);
SendKeys.SendWait("{ENTER}");
Thread.Sleep(500); // An unfortunate necessity, to give the dialog time to pop up.
SendKeys.SendWait(#"C:\myfile.jpg{ENTER}")
I don't love this solution, especially not the sleep, but it was the best I could do in under 30 mins.
If anyone has a better option, let me know!
Why do you need to select from the Dialog? Try to just set the Text:
ie.FileUpload(Find.ById("profile_file")).Text = "C:/Desktop/image.jpg";
I guess you might talk to the fellow who asked this question:
WatiN File Upload

Opening File paths with spaces in Delphi 5

(Using Delphi 5)
I am attempting to open a log file using the following code:
// The result of this is:
// C:\Program Files\MyProgram\whatever\..\Blah\logs\mylog.log
fileName := ExtractFilePath(Application.ExeName) + '..\Blah\logs\mylog.log';
// The file exists check passes
if (FileExists(fileName)) then
begin
logs := TStringList.Create();
// An exception is thrown here: 'unable to open file'
logs.LoadFromFile(fileName);
end;
If I relocate the log file to C:\mylog.log the code works perfectly. I'm thinking that the spaces in the file path are messing things up. Does anyone know if this is normal behavior for Delphi 5? If it is, is there a function to escape the space or transform the path into a windows 8.3 path?
I'm pretty sure that Delphi 5 handles spaces in filenames ok but it has been a very long time since I have used that specific version. Is the file currently open by another process? It also could be a permissions issue. Can you instead of loading it into a tStringList, try opening it with a tFileStream with the filemode set to "fmOpenRead or fmShareDenyNone".
fStm := tFileStream.Create( filename, fmOpenRead or fmShareDenyNone );
then load your tStringlist from the stream:
Logs.LoadFromStream ( fStm );
Are you sure its not the "..\" thats causing the problem rather than the spaces. Have you tried to see if it works at
c:\My\Path\nospaces\
If so and you are always using the ..\ path, maybe write a simple function to remove the last folder from your application path and create a full correct pathname.
It's odd that Delphi 5 would throw errors about this. I know of an issue with FileExists failing on files with an invalid last-modified-date (since it internally uses FileAge), but it's the opposite here. Instead of using "..\" I would consider risking the current path, and loading from a relative path: LoadFromFile('..\Something\Something.log'); especially for smaller applications, or by calling ExtractFilePath twice: ExtractFilePath(ExtractFilePath(Application.ExeName))
I'm pretty sure Delphi has always handled spaces so I doubt that is the issue.
You don't show the full path. Any chance it is really long? For example I could believe an issue with paths longer than 255 characters.
It's also a bad idea to put log files under Program Files. Often normal users are not given permission to write to anything under Program Files.
Delphi 5 can open files with spaces - that is certainly not the problem. To prove it, try copying it to c:\my log.log- it should open fine.
Is there any more information in the error message you receive? The most likely thing is that someone else (perhaps your own program) is still writing to the log.
The spaces are not a problem. While the '..' could be a problem in Delphi 5, mosts probably the file is locked by the process that writes to it. If you have control of it, make sure it opens the file with fmShareDenyWrite and not fmShareExclusive or fmShareCompat (which is the default).
Also, you can use:
fileName := ExpandFileName(ExtractFilePath(Application.ExeName) + '..\Blah\logs\mylog.log');
to obtain the absolute path from a relative path.
Also, as others have said, it is not good idea to write anything in Program Files. Regular users (that are not Administrators or Power Users) do not have rights to write there (although in Vista is will be virtualized, is is still not a good idea). Use the appropriate Application Data folder for the user (or all users). This folder can be obtained using:
SHGetFolderPath(0,folder,0,SHGFP_TYPE_CURRENT,#path[0])
where folder is either CSIDL_COMMON_APPDATA or CSIDL_LOCAL_APPDATA. See this delphi.about.com article for an example.
Simple :
// if log file = "C:\Program files\mylog.log"
// you'll get :
// »»»»» fileName = 'C:\Program files..\Blah\logs\mylog.log'
// if log file = "C:\mylog.log"
// you'll get :
// »»»»» fileName = 'C:..\Blah\logs\mylog.log'
Try this code instead, I'm pretty sure it will fit your needs :
fileName := IncludeTrailingPathDelimiter(ExtractFilePath(Application.ExeName))
+ '..\Blah\logs\mylog.log';
Regards,
Olivier
Delphi 5 has never had a problem opening files with spaces and I am still using it since it is uber stable and works great for older XP apps. You need to check your code closely.

Resources