fwrite function behaves unexpected - fwrite

I am using fwrite function. I have a file that has 4K. I want to change a field in the place 3500.
I do fseek to the place (3500) I also get it in ftell that tells me that I'm at 3500.
I do:
char[8] a;
File* f; //is opened with a+ mode
int n = fwrite(a, 1, 8, f);
Then when I open the file the data from buffer a is set to the end of the file.
Why? How to change it?

Because you opened the file with "a+", anything you write to the file will always go at the end of the file regardless of seeking to anywhere else. The "a" means you open the file in appending mode. Use "r+" for the mode instead.

Related

Start App from file storing settings and load them at startup

I'm working on an App in app designer. Within the app the user will select a bunch of options before running some calculations.
To simplify this process I added a "Save as..." menu so that the user can save the current settings to a file (.mat) and reload them when they open the app the next time.
What I'm trying to achieve is that the user can double click on the previously saved .mat file, which will launch the app and the app will automatically read the double clicked file and load all the settings.
All this needs to happen after the app is compiled and distributed as an executable.
I'm thinking that one way to achieve this is to make a startup window of the app that calls the main window passing the file path as parameter.
Any suggestion would be really appreciated.
Hi, I think I may have a fairly simple, albeit involved, solution for you.
Brief solution overview (TL;DR)
Save the settings from the app with an extension other than .mat, e.g. .mydat. Add an App Input Argument and have the startupFcn treat the argument as a file name to a *.mydat file and be sure to also handle the case that the argument is left out. After the first output file is saved, use windows Open with... to select your app. Now double clicking the *.mydat file will open your app's .exe and will provide the file name of the clicked file to the input argument in your startupFcn.
An example in MATLAB 2018a as a compiled exe on windows 10.
Ok, to start. Let's setup a simple app (I called it runAppFromData) that takes a string input to an edit field and saves it in a file called 'settingsValues.mydat'. It looks like:
The callback for the Save button collects the Value into a local variable called value and then saves it to disk:
% Button pushed function: Save
function save(app, event)
value = app.InputField.Value;%#ok
% User selects save location
saveLocation = uigetdir();
% Now just save the value variable to the selected location.
save(fullfile(saveLocation,'settingsValues.mydat'), 'value', '-mat');
end
I don't know when appdesigner added the feature to "run app with inputs" but I have it with 2018a:
We make a single input, fileName that expects a file name as a string (you'll see why below). So add the input and click OK. Then we're sent to "code view" at the startupFcn. Here we'll write the logic that parses the input file. For my simple example app, I load the input file into a struct and then send the value to the edit field:
% Code that executes after component creation
function startupFcn(app, fileName)
if nargin < 2 % app is itself an argument
% just continue running the application without error
return
end
% fileName is a string, so let's load it into a struc
S = load(fileName, '-mat');
% The value field will be there because that is how we wrote it
app.InputField.Value = S.value;
end
Note, I performed a nargin check to handle the first-run case (and anytime the app is run from the actual executable).
MATLAB doesn't care what the file extension is of a matlab file and if you have an unknown file extension, e.g. .mydata, double-clicking the file in windows will ask you to choose the application, which works to your benefit for deployment:
A couple things to consider.
When the app is opened from the .exe it will always show the default values. If you want to input some other default values you can edit your windows shortcut Target field to supply a file path for the desired input file (see here). This saves recompiling with new defaults, but the file has to remain somewhere (you can package it with the app too).
Sorry this answer got soo long! I hope it helps!
You can't double click a .mat file and open an entire executable, but you can definitely add a startup function that asks you to open a .mat file. My suggestion though would be to make sure that you have a template file at least in place, so that the user doesn't run into problems the first time running the program where there is no file to open.

Keep Matlab from stepping into built in functions during dbstop if error

I use dbstop error a lot when working in Matlab. A good portion of the time, a mistake causes errors to be thrown inside of built-in [m-file] functions, which then causes Matlab to stop execution and open the file. However, it's almost never helpful to debug inside of the built-in file, so this ends up disrupting my workflow. Might there be a way to set things up so that Matlab backs out of the built-in file in the debugger (never opening it), leaving me at the function call?
Although I've never found a way to tackle this problem properly, it's fairly easy to hack together a workaround:
Create a script containing something along these lines:
S = dbstack();
file_paths = cellfun(#which, {S.file}, 'UniformOutput', false);
builtins = ~cellfun('isempty', strfind(file_paths, matlabroot()));
stack_depth = find(~builtins, 1, 'first');
for ii = 1:stack_depth-1
dbup(); end
Save it somewhere that makes sense to you, and place a shortcut to it in the MATLAB toolbar.
Then, whenever this problem occurs, you just click on your little shortcut, which will automatically take you to the first non-builtin function in the debug stack.
Based on Rody's answer and feedback from Mathworks, this is the closest you can get at this point (R2016b):
S = dbstack('-completenames');
builtins = ~cellfun('isempty', strfind({S(:).file}, matlabroot()));
stack_depth = find(~builtins, 1, 'first');
hDocument = matlab.desktop.editor.findOpenDocument(S(1).file);
matlab.desktop.editor.openAndGoToLine(S(stack_depth).file,S(stack_depth).line);
hDocument.close();
if stack_depth == 2
dbup();
end
This shortcut will:
Open up the closest user function to the correct line.
Close the builtin function that opened when the error was thrown.
If the error happened only one level away from a user function, switch to that workspace.
The problem is that dbup() only works once - after the call, execution in the script stops. There's no function to switch to an arbitrary place in the stack.

Is it possible to undo close tab in Matlab's editor?

Many web browsers allow to undo close tab:
Is it possible to undo close tab in Matlab's editor?
I use R2014a on Windows 7.
It isn't officially supported in MATLAB, but with reference to Undocumented MATLAB, there is a workaround.
MATLAB stores its Desktop windows state in a file called MATLABDesktop.xml that is located in the user’s prefdir (preference directory) folder. You can echo where this is in MATLAB by simply typing in prefdir in the Command Prompt and pushing Enter or RETURN. As you are also using Windows, you can also do this to open up the folder within MATLAB:
winopen(prefdir);
This should open up a new Windows Explorer window that will directly bring you to the prefdir folder.
This file includes information about the position and state of every Desktop window. Since the editor files are considered Desktop documents, they are also included in this file. As such, when you close the editor, these documents are simply removed from the MATLABDesktop.xml file.
It turns out that MATLAB automatically stores a backup version of this file in another file called MATLABDesktop.xml.prev, in the same prefdir folder. I'm also using MATLAB R2014a in Windows 7 and I have double-checked to see if these files are also on my system and they are!
So before doing anything else, close MATLAB, delete the latest MATLABDesktop.xml file, replace it with a copy of the MATLABDesktop.xml.prev file, renaming it to MATLABDesktop.xml. After, restart MATLAB and the editor should reopen with your previous tabs.
You may use the following code. It extracts the file names from MATLABDesktop.xml.prev
%parse XML file
xmlFiles = xmlread([prefdir filesep 'MATLABDesktop.xml.prev']);
%Retrieve the "clients"
FileNodes = xmlFiles.getElementsByTagName('Client');
%get the length of the FileNodes
nrFiles = FileNodes.getLength;
%initialize Files
Files = cell(nrFiles,1);
%initialize isFile
isFile = zeros(nrFiles,1);
%Iterate over all Elements and check if it is a file.
for iNode = 0:nrFiles-1 % Java indexing.
%Files
Files{iNode+1} = char(FileNodes.item(iNode).getAttribute('Title'));
%check if the "client" is a file:
isFile(iNode+1) = exist(Files{iNode+1},'file') == 2 && ~(strcmp(Files{iNode+1},'Workspace'));
end
%remove the other files:
MyFiles = Files(find(isFile));
%open the files in the editor:
edit(MyFiles{:});
From mathworks

Can I use emacs to copy a line from other window to my current one?

Suppose I have to code files which are supposed to be similar but has some minor changes. For example, file foo:
int a,b,c
a=1
b=2
c=3
and file bar
int a,b,c
a=1
b=2
c=4
I know that I'm better of placing the changes in a properties file but, It is harder to follow that way. Now, suppose that I need to change the files to be (foo) in this example
int a,b,c,d
a=1
b=2
c=3
d=a+b+c
After I've changed one file, I want to compare the two files, and apply the desired changes to my files. Currently, what I'm doing is open two windows and compare them (M-x compare-windows). When I encounter a line that I want to change, I copy it from foo to bar (adding to kill ring etc.) I'm quite certain there is a better way to do it. Do you know it?
Seems you are looking for M-x ediff-buffers RET, resp. M-x ediff-buffers3 RET

vimscript copy paste variable

i have the following command in my .vimrc:
nmap gtb texecute "!perl /home/hermann/hi.pl ".shellescape(getline('.'), 1)
it executes a perl script and sends whichever line the cursor is over, to it.
how do i send to the script whatever is in the copy-paste buffer instead?
There is no single 'copy-paste' buffer in Vim, there is a set of named registers instead. You can get the contents of a register using getreg function - it has a single argument, register name. For example, use this to get the contents of a default yank/paste buffer:
getreg('0')
you can use the 'normal' function to paste the clipboard contents.
function MyPastingFunc()
"paste from clipboard
normal! "+p
"do more stuff
endfunction