Opened 12 years ago
Closed 12 years ago
#2097 closed defect (fixed)
OMEdit 1.9.0 Bitmap import does not work
Reported by: | anonymous | Owned by: | Adeel Asghar |
---|---|---|---|
Priority: | high | Milestone: | 1.9.0 |
Component: | OMEdit | Version: | trunk |
Keywords: | Cc: |
Description
Hello, I am using OMEdit 1.9.0 on WinXP. When I go to the icon layer and use the bitmap import option I get the following error:
Scripting 17:27:57 0:0-0:0 Fehler in KlassenanmerkungError occured building AST
Syntax Error
[<interactive>:1:546-1:546:writable] Error: Lexer failed to recognize '∢, imageS'
[<interactive>:1:547-1:547:writable] Error: Lexer failed to recognize '��, imageSo'
[<interactive>:1:548-1:548:writable] Error: Lexer failed to recognize '�, imageSou'
Attachments (1)
Change History (10)
comment:1 by , 12 years ago
comment:2 by , 12 years ago
The image parsing code in OMEditGUI/BitmapAnnotation.cpp seems a bit off. Look at this code:
if(mImageSource.isEmpty()) { annotationString.append(", fileName="); annotationString.append('"'); annotationString.append(mFileName); annotationString.append('"');
Are we really sure that mFileName has something valid in it?
My problem is a bit different. I've got a component with a bitmap in its Icon. I see that OMedit fetches the Icon annotation thusly:
Bitmap(true, {0.0, 0.0}, 0, {{-100, -100}, {100, 100}}, "modelica://GoodStuff/warningIcon.png")
It transforms it to the list
[true, 0.0, 0.0, 0, -100, -100, 100, 100, "modelica://GoodStuff/warningIcon.png"]
It finds the filename, then strips the quotes off it. It then calls QDir on it! Does that work?! Doubt it. It needs to check for a URI, then the type of the URI, and handle the various different URI types appropriately.
comment:3 by , 12 years ago
Or perhaps omc is supposed to be resolving these things to an absolute path on the system? In which case it's omc's fault for sending the URI to OMedit in the first place.
comment:4 by , 12 years ago
Here's a patch which fixes my problem. My version of OMCProxy has evolved a bit, so the line numbers will be off.
by , 12 years ago
comment:5 by , 12 years ago
Whoops. Bad version of the fix. Updated. There's still another bug, which is ensuring that the MODELICAPATH used by omc supports all the libraries loaded into OMedit.
comment:6 by , 12 years ago
Well... In OMEdit all libraries are already loaded. And if a class is loaded the modelica:// link should work. And if a library uses modelica:// links to some library that was not loaded... the library did not use a uses-annotation as it should. Note that case-insensitive matching for mOdElica:// has to be performed. The API call takes care of all these things; the only reason to do this in OMEdit is to sometimes save a little time (all libraries should use modelica:// links after all).
The following exists in source:branches/OMEdit, so it should be a little more mature
/*! Takes the Modelica file link as modelica://Modelica/Resources/Images/ABC.png and returns the absolute path for it. \param uri - the modelica link of the file \return absolute path */ QString OMCProxy::uriToFilename(QString uri) { sendCommand("uriToFilename(\"" + uri + "\")"); QString result = StringHandler::unparse(getResult()); printMessagesStringInternal(); return result; }
comment:7 by , 12 years ago
When I look at the OMC Logger trace, I see the command 'uriToFilename("modelica://GoodStuff/foo.png")' going out from OMedit to omc, and nothing coming back. OMedit has already loaded the GoodStuff library, so I presumed that omc also knows about it. But apparently not...
comment:9 by , 12 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Bitmap annotations are now handled properly.
Yeah, I can't seem to get OMedit to display any Bitmap elements of an Icon, either.