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)

a.diff (1.8 KB ) - added by Bill Janssen 12 years ago.

Download all attachments as: .zip

Change History (10)

comment:1 by Bill Janssen, 12 years ago

Yeah, I can't seem to get OMedit to display any Bitmap elements of an Icon, either.

comment:2 by Bill Janssen, 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 Bill Janssen, 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 Bill Janssen, 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 Bill Janssen, 12 years ago

Attachment: a.diff added

comment:5 by Bill Janssen, 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 Martin Sjölund, 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 Bill Janssen, 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:8 by Martin Sjölund, 12 years ago

It will only succeed if the file foo.png actually exists there.

comment:9 by Adeel Asghar, 12 years ago

Resolution: fixed
Status: newclosed

Bitmap annotations are now handled properly.

Note: See TracTickets for help on using tickets.