I am quite familiar with MATLAB, although not so much with writing GUIs in it. Now my boss gave me a MATLAB program with GUI which was developed on a Windows machine and runs there without problems. I copied it to my mac (osx 10.6.5 with MATLAB R2009b) using a USB memory stick and tried to work on the files on my computer.
When starting the GUI, some of the callbacks are executed, some not. I was able to open the figure file containing the GUI in GUIDE, but there cannot click on the callback fields in the Property inspector. Also some components are not shown in GUIDE which are visible when running the GUI. First I suspected it might be corrupted by changed newline characters, but learned that .fig files are binary, so this should not be the case. I opened the binary .fig file with a text editor and found the following ASCII line followed by binary data:
MATLAB 5.0 MAT-file, Platform: PCWIN, Created on: Tue Aug 10 17:11:57 2010
Are the GUIs created with MATLAB OS specific? Wouldn't this be really stupid?
I opened the files on the windows machine again and tried to export them or save them by specifying that I want them to be compatible with other operating systems but could not find an option like this.
Of course I researched this on google, and wondered that I did not really find something related. If an incompatibility exists, I think this would have been discussed, right?
Anyone knows about it or had the same problem before?
Hmmm, ok. Well, the answer is quite embarrassing but still bears some potential to learn from it. The folder that my boss gave me contained a lot of files and figures with similar names, like:
bla1.fig
bla.fig
bla0.fig
the simple problem was, the first time I opened the figure with GUIDE I opened figure bla.fig instead of bla1.fig. After this I always used the reopen function of GUIDE and did not see that it was always the wrong file. this caused the problems.
==> so there is no incompatibility between Mac and PC, although I wonder why the platform is written in the file then
==> it could have been a problem with backwards-compatibility as the original figure was created with MATLAB 5
==> as #Adrian and #Mikhail pointed out: it would be very very useful to use a Version control system in order to prevent to have hundreds of files with different numbers where most of them are of no use anymore
There seems to be some incompatibilities between different platforms and also between different versions, from my experience (MATLAB 5, 6, and 7) also -- I've encountered similar situations many times.
I am not exactly sure when the GUIDE became available with MATLAB -- I first noticed about it when I was using the first version of MATLAB 7. (It used to be very unstable at first, but is very usable now. For example, I vaguely remember a critical issue with MATLAB 7 Student version. You had to download a patch to make the GUIs work.)
Does your boss know how the *.fig file was created and in which MATLAB version? Can you open the *.fig on the old version of MATLAB and display the GUI correctly?
Some functions have possibly become obsolete since the earlier version of MATLAB that was used to create the figure, and may be causing some minor problem with it. If that is the case, you can troubleshoot it by checking all the error and warning messages that appear on the Command Window (or the MATLAB Console.)
Also, you should be able to load the *.fig files on the workplace using the following command from the Command Window, assuming that the files are in MATLAB's search path.
load your_file.fig -mat
You should then see a structure dataset, and see all of the figure properties, etc. in that structure.
You can use the information to create a new figure without the GUIDE (GUI Development Environment / Tool).
I recommend you writing your own GUI app. It's not that difficult, with/without the GUIDE.
I recently opened a site with some Tips on MATLAB Programming for beginners and intermediate users, and update it in my spare time. If you have any specific question about GUI building, I may (or may not) be able to provide answers there...
Related
This is a strange circumstance that my boss and I just got into this morning as we were trying to import my scene from the Team Foundation Server to his machine. I created a Unity Scene file and made my scene over the course of the past month or so and when I was finished I uploaded everything to TFS so he could pull it down and use it (we are quite far apart from each other so we can't just usb drive everything over to see what the problem might be). When he pulled the scene file down (and all the supporting scripts) one of the scripts that was in the scene was changed. It started out being a script called Smart_HUD4 but when he went in to the inspector the script was now called Smart_HUD2 and was an entirely different script than what I had written, not to mention I don't even have a Smart_HUD2 script on my machine. The same also applied to another script called laser (now called Laser1 and again, not something I wrote nor is it on my machine).
Has anyone else come up against a problem like this? Found any solutions? It's strange because I went ahead a re-downloaded the files I uploaded and everything was exactly how it was supposed to be, proper names and scripts in their proper places. We think the issue is because we are moving from Windows to OSX and the differences in operating systems might be leaving behind some residual code or something that is causing things to be switched around?
TFS never asked me to merge any files so if it is the case that TFS might be auto-merging files, none of the files its merging even share the same name, its just picking ones whose names are close and doing so (the scene file's name was completely unique so it has nothing to merge that with).
OK, few things to check:
Have you checked that the files do not exist in the TFS with similar naming? regardless of TFS requesting name changes?
do you have any other projects effected?
Have you checked (I'm guessing you have) that the unity versions are matching exactly?
Now, something to consider, The unity system does vary between Windows and MacOS, mainly in the fact that Unity Makes use windows bases features that are not present on a Mac and this can cause file issues.
When moving between systems, Unity packages the scene data on windows in a global and local format. So, sometimes folder structure can change.
From experience, the most likely issue is more to do with file locations than OS discrepancies, as it might have been a clash between your project and other similar.
Remote file management is odd at times when doing colab stuff. Have you checked with other colleagues made sure they don't have anything similar uploading?
But, scripts changing names and data is not something that I would expect. So my guess is that the issue lies with the upload on the TFS and not the MacOS vs Windows move.
Hope this helps,
Glenn
I am in a process of learning things in reverse order for fun, and I have decided to dissect Windows 10, bit-by-bit, and learn what makes a great OS function. And I also suppose that my question will be geared in other ways as well.
My question is, how do I look at something like Windows bootmgr source code properly? I have opened the file - which the file type is redundantly called "File" - and even though it is in Assembly language, it is completely impossible to read. My guess is that whoever wrote the File did something to encrypt the File so that it is unreadable, and thus unchangeable/unable to be edited.
Let me be perfectly clear: my purpose is not to change the bootmgr File to change windows, but rather to get a better understanding of how an OS works via reading, and also through trial and error.
Any help that anyone can give would be greatly appreciated. I love to learn about these things, and I just have been completely unable to find the answer I am looking for on any site thus far, including this one...IDK if I need to refine my searches or what.
Thank in advanced for your help. :)
Ps. I shall include a picture of what I am seeing in Notepad++ so you can get a better understanding of what I need here .
I think you may be confusing assembly language with machine code. Machine code is the language that your computer's processor understands. Assembly language is a series of symbols that are used to represent machine code. Compiled executables are stored in machine code.
That said, the standard way to view the machine code for a compiled binary is through the use of a program called a hex editor. A hex editor will display the binary code in a numerical format, rather than attempting to interpret the binary as text, like your editor is trying to do in the screenshot you supplied. Frhed is a popular hex editor, but there are many good ones to choose from.
My company does Linux embedded systems using Freescale PowerPC processors.
Some years back I wrote an internal HowTo on how to use Dan Kegel's crosstool to set up a cross compiler environment for our product. I hadn't touched it since then but I recently tried it and found it doesn't work. The scripts look for files on redhat.com's ftp server that are currently not there.
The latest cross tool script is the one I am using, version 0.43.
So before I roll up my sleeves and see if I can fix it myself, I am wondering if someone has already done this. Does anyone here know Kegel well enough to contact him and ask if he is planning to do an update? (My guess is not. He works at Google now.)
Alternatively, is there a better GNU cross tool builder than Kegel's cross tool? It might be easier to switch over than to update the old one.
As it turns out Mr. Kegel was kind enough to respond to my e-mail. It turns out his original scripts have been picked up by an open-source group that calls it crosstool-ng. They did an amazing amount of work on this and the tool now uses a curses-based menu system to select the options for the cross development to generate.
You can search for file names directly in Google (try '<filename> site:ftp.redhat.com' or something similar), and often results will yield revised links to the files. If that is the problem, it should just be a case of cut and paste. Alternately, I would recommend downloading the files locally, modifying the script to see them there and then bundling them with the script.
Kegel left Google for a startup. His resume is at http://www.kegel.com/resume.html . Have you tried emailing him? He might just respond.
Microsoft's "Windows Installer CleanUp Utility" could be used to help fix broken installations of MSI-installer based products. When the installer failed in some strange way and left corrupt data behind, so bad that even Add/Remove Programs couldn't help, you could often fix things by running this utility and then running the application's installer again.
I just discovered that Microsoft announced a couple weeks ago that they were discontinuing this utility. They didn't merely say "we're not supporting it anymore"; they seemingly removed it from their site entirely.
I have to support a Windows program for a whole bunch of users. Given the number of users, every so often something will go wrong, and this program has been invaluable for me, as a last-ditch line of defense.
I know I could point customers to some third party site that has a cached copy of it, but this seems dangerous (malware potential and such).
So, are there any replacement products? Or, if not, how can I myself do whatever it is that this program did?
To be clear, I'm not asking for help like "how do I programatically modify the registry". I can do that fine. But I need to know what in the registry needs to be modified.
Thanks in advance.
Windows Installer CleanUp utility was never intended to be used in the wild. It was only meant to be used by software developers. If you occasionally have end users needing to use WCU you have some serious installer quality issues that should be addressed.
WCU only removes the Windows Instaleller meta data and doesn't actually uninstall any software. This leaves the machine in a very dirty state. These days with test labs becoming virtualized there's no reason to have this tool anymore. You just roll back to a prior snapshot and keep on working.
I've seen all kinds of online forums full of users who think they know what they are doing ( and don't ) suggest using WCU to solve various problems so in the end Microsoft decided to try to get the horse back in the barn.
I have old copies of WCU archived in my CM system so if you'd like me to generate checksums to help you determine if you are getting a good copy just let me know.
The cleanup utility was a wrapper around the command line utility msizap.exe, described here:
http://msdn.microsoft.com/en-us/library/aa370523%28VS.85%29.aspx#1
OK, the Windows dev platform I have is a Windows XP box and a copy of Visual C++ 6.0. I'm trying to create or modify security descriptors for a service. My initial thought from other answers (and some reading) was that I should use ConvertStringSecurityDescriptorToSecurityDescriptor to setup my security descriptor.
Except...my install of VC++ 6.0 lacks the headers for this function (sddl.h according to MSDN).
Can anyone point me to other APIs for creating/modifying Security Descriptors? I'd be happy if I could walk through an existing one (I can QueryServiceObjectSecurity) and just eliminate certain users, but I can't figure out how to do that just looking at MSDN.
Alternately, if someone could point me in the direction of how to call this function without proper headers, that would be fine.
Obvious answer rebuttal: I can (and will) make an attempt to get IT to install a newer version of VC++ on my system, but the last time I asked IT about anything significant it took 7 weeks for them to respond. Since I'd like to get this done in the next week or two, I think IT is not going to fix this question for me in a timely manner.
In theory, you don't need a newer compiler, just an updated SDK. In reality, VC++ 6 is old enough that it may have trouble parsing the headers for a current SDK though.
As an alternative to that, you could declare pointers to the correct types of functions in your code, then use LoadLibrary and GetProcAddress to get the addresses of the correct functions, then call the functions via those pointers.
As an aside, however, I'd point out that I doubt what you've envisioned will work. I've never tried to do exactly what you're trying, so it's always possible I'm wrong, but every time I've done anything manipulating security descriptors, DACLs, SACLs, or anything similar in Windows, the code's ended up considerably longer and more complex than it initially seemed like it should. Even something extremely trivial generally requires at least a couple hundred lines of code...
You could check out the DCOMPerm sample, it has handles the DACL/ACE and other structures you are going to run into - thats where i started when i created a set of classes to handle this for our COM installations - and as #jerry coffin said it ended up being a lot of code.
You'll have to download the SDK to get the sample.