- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi there,
the topic says it all. In a module globaleVariablen I set the variable dtMain = 0.2. Using IVF14 to watch that variable in a subroutine or function, it has only a value in a watch window, when it is actually being used there. IVF12 doesn´t has this behaveiour. I uploaded a picture that describes it.
Is there some project setting I have to set in IVF14?
Thanks in advance,
Markus
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
A way around this is to prefix the variable name with the module name in your watch :
moduleName::varName
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Markus -
Please try adding the modulename to the variable in the watch window, as globaleVariablen::dtMain
If that does not work, let us know --
--Lorri
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It works. A little bit...
When a variable is declared like this, it doesn´t work:
[fortran]
module Shared_Common
integer(kind=4):: iGUIModus = 7834689
!DEC$ ATTRIBUTES DLLEXPORT :: iGUIModus
end module Shared_Common
[/fortran]
Without DLLEXPORT, it works (like the dtMain example):
[fortran]
module GUI_Common
integer(kind=4) :: plotEnergiebilanzSelektion = 0
end module GUI_Common
[/fortran]
This is odd. First, the workaround module::variable is not very practical and time consuming (you can´t just click right and say Add watch) and secondly this doesn´t even work in all cases.
Markus
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
So, there is no chance to watch a variable with the DLLEXPORT attribute in IVF14?
Markus
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The modname::varname doesn't seem to work for a variable in a DLL-imported module, whether it is used or not. But such variables do show in the Locals list if they are used in the scope. It seems to work fine for references within the same "target" - that is, if you're in the DLL and use the :: syntax to view a variable from another module in the same DLL, you can see DLLEXPORTed variables just fine.
I will ask the developers if they can make this work.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Steve, it works perfectly when choosing the IVF12.1 compiler. It´s very nasty...
I still have to convince my boss to buy a new license. This behaviour will not raise my chances :-)
Markus
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ok, thanks, I'll check into that.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Markus, I can't reproduce this working any differently with the 12.1 compiler. In both 12.1.5 and 14.0, using the module::var syntax doesn't show an unused but exported variable from a DLL. If the variable is used, then it shows in the Locals list. Can you put together for me an example that shows otherwise?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I altered the DLL_Shared_Data sample to show the issue.
In main.f90, line 83 the user sets shared_variable by keyboard input. Then I added a call to a subroutine at line 84 to test the value of shared_variable.
Take a look at the pictures. In IVF 14 I can only see what value shared_variable has, when I actually use it in the subroutine.
Thanks for investigating this!
Markus
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Short update: The problem still exists with the IVF14.0.1.139 Update1 compiler...
Markus
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Steve, is this under investigation? I provided a solution that shows the behaviour...
Markus
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It is still under investigation.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page