I can't get the report preview to work. When I was evaluating c2j i am pretty sure i have seen the report preview working in the cookbook example. Now even in the cookbook example the report immediatelly goes to the printer. I have tried to change the default printer but the behaviour is the same.
Since I have not recompiled the cookbook example I am a bit puzzled.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Now i start to doubt about my memory. I have started to dig in the ABC and I reached the point where it seems as the CREATE command is not implemented in c2j, at least not for IMAGE control. If this is the case then the default ABC previewer is not usable as it relies on that heavily. I suppose you use some other previewer.
If this is the case i will not use previewer, although I am not happy with that. I will try to find a workaround anyway.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
case Create.IMAGE: // constant
ac = new ImageControl();
break;
case Create.ITEM: // constant
ac = new ItemControl();
break;
Now i get the preview, although is ugly and is not really showing the report preview, but at least is not crushing. Any reason why these lines showuldn't be added to createControl?
thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes above lines should be added. I only added controls as I needed them.
For my own app, I created my own preview system. I never looked into getting ABC preview working; I believe it does not work very well. I will take a look at example and see what it takes to get it working.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have made some progress, but I have to park it for a while as other tasks now demand my attention.
Things I fixed:
* got toolbar working properly
* change to compiler to deal with bug with ABUTIL in clarion 6. LOOP x=A TO B bY C was originally implemented as a for loop in java; but behaviour is subtly different. Now fixed.
* Images are now able to tell ABREPORT how big they are
* Combo control dynamic setting Prop:from now works; so too with report {prop:preview}
Things to do:
* combo control dynamic setting of prop:from needs to pay attention to field passed, do not assume that first field in a queue is the one to display
* zooming/sizing on image is not behaving as I would expect it, not sure why just yet. I suspect it relates to how c2j currently calculates window CLIENTWIDTH and CLIENTHEIGHT. I think these should be based on size of content pane, not the window.
* popup() not yet implemented. Needs to be implemented
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for your effort. Zooming and popup are not important to me. I just need simple previwer with a button for printer dialog and the possibility to preview all pages with PageDown. As for clientsize in past I have done some coding to find the size of the window and of the client part of the window and I come to
if not getwindowrect(target{prop:handle},rc)
return 0
end
if not getwindowrect(target{prop:clienthandle},rcC)
return 0
end
I then used rcC for something, so yes i think clientwidth,height should be based on prop:clienthandle, if this is the matter.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There are some ABC library code you will need to modify. I cannot easily modify c2j to replicate behaviour of clarion in these instances.
Change 1: In ABUTIL
ConstantClass.GetShort PROCEDURE()
RVal SHORT,AUTO
CODE
RVal=SELF.GetUShort() !Req'd for type conversion
! The following line is necessary for C2J
if RVAL>32767 THEN RVAL=RVAL-65536.
RETURN RVal
Rationale for above: c2j does not precisely mirror memory model used by clarion. In c2j all numbers are stored as unsigned integers. It only uses memory model when doing things like OVER. I intend to keep c2j the way it is because I believe any change will weaken c2j on basis that we are deliberately increasing the likelihood of bit wraparound. Even though code in question explicitly relies on this, it is poor programming practice to do this; particularly in the business language where the idea is to shield the programmer from the limitations and subtleties of how things are represented in memory and on CPU. The whole notion of a ConstantClass, and how it is built irritates my sensibilities as a business language programmer, so I will not modify c2j to accommodate it.
Change 2: in ABREPORT.CLW
THeight=SELF.ImageHeight*ZoomModifier
!UNHIDE(SELF.ImageFeq) ! commented out here for c2j. The unhide occurs further down
SELF.ImageFeq{PROP:MaxWidth}=TWidth
SELF.ImageFeq{PROP:MaxHeight}=THeight
SETPOSITION(SELF.ImageFeq,0,0,CHOOSE(TWidth<=WinWidth,TWidth,WinWidth),CHOOSE(THeight<=WinHeight,THeight,WinHeight))
SETPOSITION(SELF.BorderFeq,0,0,CHOOSE(TWidth<=WinWidth,TWidth,WinWidth),CHOOSE(THeight<=WinHeight,THeight,WinHeight))
SELF.ImageFeq{PROP:HScroll}=CHOOSE(TWidth>WinWidth)
SELF.ImageFeq{PROP:VScroll}=CHOOSE(THeight>WinHeight)
SELF.BorderFeq{PROP:Hide}=CHOOSE(THeight>WinHeight AND TWidth>WinWidth)
UNHIDE(SELF.ImageFeq) ! moved here for c2j
Rationale: order of unhide is very important; problem with original code is that image was unhided before the box. The result was that the box would occlude the image. clarion occlusion I have not quite figured out but it appears to work on multiple layers depending on the control type. c2j is fore more primitive; it is in the order that controls are defined (or in case of dynamic controls the order they are unhidden) defines painting order. I once tried to replicate clarion model, but it is too difficult to understand so I just left c2j as is.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have done as above and updated the runtime but i got crash as:
java.lang.NullPointerException
clarion.Iniclass.fetch(Iniclass.java:232)
clarion.Printpreviewclass.display(Printpreviewclass.java:346)
clarion.Printpreviewclass.display(Printpreviewclass.java:311)
clarion.Printpreviewclass.display(Printpreviewclass.java:315)
clarion.Printpreviewclass.display(Printpreviewclass.java:319)
clarion.Reportmanager.askPreview(Reportmanager.java:122)
clarion.Reportmanager.takeCloseEvent(Reportmanager.java:356)
clarion.Windowmanager.takeWindowEvent(Windowmanager.java:828)
clarion.Reportmanager.takeWindowEvent(Reportmanager.java:473)
clarion.Windowmanager.takeEvent(Windowmanager.java:673)
clarion.Windowmanager.ask(Windowmanager.java:237)
clarion.Reportmanager.ask(Reportmanager.java:114)
clarion.Windowmanager.run(Windowmanager.java:490)
clarion.Wmj064.stampTec(Wmj064.java:33)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks, it works now. I think i will change ABC class because at button print it just flushes to default printer without asking me number of copies or other printer. Anyway is great I have at least this.
As for "irritates my sensibilities as a business language programmer" I completely agree/understand with you, you do not know how much.
Thanks again
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have noticed for now just one strange thing: if i resize the preview window the image is not displayed if i resize wider or longer than the image itself; i.e. if the vrtical or horizontal scrollbar disapears. I will investigate if it is c2j or abc.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Follow on.
If intially the preview window is larger than the image then i can resize how i wish without loosing the image.
If initally the preview window is not larger than the mage then if i resize wider i loose the image.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Follow up.
While testing I have noticed that when I have multipage report the SPIN control allows me to choose nuber of page higher than max page number.
I have implemented a workaround.
It seems to me that
SELF.PrtPrev:CurrentPage{PROP:RangeHigh}=RECORDS(SELF.ImageQueue)
fails; i.e. maybe c2j does not handle correctly prop:rangehigh
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
HIGH and LOW ranges are obeyed by spin control. I suspect that SPIN currently does not respond properly to dynamic changes to hi/lo range. Looking at code I suspect it will work if you key in the amount, it will check dynamic ranges.but if you click on up/down arrows I think these will only obey ranges set when control is initially created. Probably quick hack fix is in SpinControl. configureModel() should be called via adding tests for hi/lo range in isAWTChange() and handleAWTChange()
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have found the reason for loosing the image.
SELF.BorderFeq{PROP:Hide}=CHOOSE(THeight>WinHeight AND TWidth>WinWidth)
If I set this to
SELF.BorderFeq{PROP:Hide}=false
it is OK.
I think it has to do with different c2j and clarion control layering, as you are awere of.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I can't get the report preview to work. When I was evaluating c2j i am pretty sure i have seen the report preview working in the cookbook example. Now even in the cookbook example the report immediatelly goes to the printer. I have tried to change the default printer but the behaviour is the same.
Since I have not recompiled the cookbook example I am a bit puzzled.
Now i start to doubt about my memory. I have started to dig in the ABC and I reached the point where it seems as the CREATE command is not implemented in c2j, at least not for IMAGE control. If this is the case then the default ABC previewer is not usable as it relies on that heavily. I suppose you use some other previewer.
If this is the case i will not use previewer, although I am not happy with that. I will try to find a workaround anyway.
I have added to CWin.createControl the following
case Create.IMAGE: // constant
ac = new ImageControl();
break;
case Create.ITEM: // constant
ac = new ItemControl();
break;
Now i get the preview, although is ugly and is not really showing the report preview, but at least is not crushing. Any reason why these lines showuldn't be added to createControl?
thanks
Yes above lines should be added. I only added controls as I needed them.
For my own app, I created my own preview system. I never looked into getting ABC preview working; I believe it does not work very well. I will take a look at example and see what it takes to get it working.
I have made some progress, but I have to park it for a while as other tasks now demand my attention.
Things I fixed:
* got toolbar working properly
* change to compiler to deal with bug with ABUTIL in clarion 6. LOOP x=A TO B bY C was originally implemented as a for loop in java; but behaviour is subtly different. Now fixed.
* Images are now able to tell ABREPORT how big they are
* Combo control dynamic setting Prop:from now works; so too with report {prop:preview}
Things to do:
* combo control dynamic setting of prop:from needs to pay attention to field passed, do not assume that first field in a queue is the one to display
* zooming/sizing on image is not behaving as I would expect it, not sure why just yet. I suspect it relates to how c2j currently calculates window CLIENTWIDTH and CLIENTHEIGHT. I think these should be based on size of content pane, not the window.
* popup() not yet implemented. Needs to be implemented
Thanks for your effort. Zooming and popup are not important to me. I just need simple previwer with a button for printer dialog and the possibility to preview all pages with PageDown. As for clientsize in past I have done some coding to find the size of the window and of the client part of the window and I come to
if not getwindowrect(target{prop:handle},rc)
return 0
end
if not getwindowrect(target{prop:clienthandle},rcC)
return 0
end
I then used rcC for something, so yes i think clientwidth,height should be based on prop:clienthandle, if this is the matter.
ok. Got some solid outputs now.
There are some ABC library code you will need to modify. I cannot easily modify c2j to replicate behaviour of clarion in these instances.
Change 1: In ABUTIL
Rationale for above: c2j does not precisely mirror memory model used by clarion. In c2j all numbers are stored as unsigned integers. It only uses memory model when doing things like OVER. I intend to keep c2j the way it is because I believe any change will weaken c2j on basis that we are deliberately increasing the likelihood of bit wraparound. Even though code in question explicitly relies on this, it is poor programming practice to do this; particularly in the business language where the idea is to shield the programmer from the limitations and subtleties of how things are represented in memory and on CPU. The whole notion of a ConstantClass, and how it is built irritates my sensibilities as a business language programmer, so I will not modify c2j to accommodate it.
Change 2: in ABREPORT.CLW
Rationale: order of unhide is very important; problem with original code is that image was unhided before the box. The result was that the box would occlude the image. clarion occlusion I have not quite figured out but it appears to work on multiple layers depending on the control type. c2j is fore more primitive; it is in the order that controls are defined (or in case of dynamic controls the order they are unhidden) defines painting order. I once tried to replicate clarion model, but it is too difficult to understand so I just left c2j as is.
Correction above: i say unsigned integers. I mean signed 32bit integers.
I have done as above and updated the runtime but i got crash as:
java.lang.NullPointerException
clarion.Iniclass.fetch(Iniclass.java:232)
clarion.Printpreviewclass.display(Printpreviewclass.java:346)
clarion.Printpreviewclass.display(Printpreviewclass.java:311)
clarion.Printpreviewclass.display(Printpreviewclass.java:315)
clarion.Printpreviewclass.display(Printpreviewclass.java:319)
clarion.Reportmanager.askPreview(Reportmanager.java:122)
clarion.Reportmanager.takeCloseEvent(Reportmanager.java:356)
clarion.Windowmanager.takeWindowEvent(Windowmanager.java:828)
clarion.Reportmanager.takeWindowEvent(Reportmanager.java:473)
clarion.Windowmanager.takeEvent(Windowmanager.java:673)
clarion.Windowmanager.ask(Windowmanager.java:237)
clarion.Reportmanager.ask(Reportmanager.java:114)
clarion.Windowmanager.run(Windowmanager.java:490)
clarion.Wmj064.stampTec(Wmj064.java:33)
Ah yes. I get this too. It is a bug in ABC itself. I assumed I must have an old buggy ABC library set.
in ABREPORT.CLW look for this, in method PrintPreviewClass.Display
Replace it with this:
Thanks, it works now. I think i will change ABC class because at button print it just flushes to default printer without asking me number of copies or other printer. Anyway is great I have at least this.
As for "irritates my sensibilities as a business language programmer" I completely agree/understand with you, you do not know how much.
Thanks again
I have noticed for now just one strange thing: if i resize the preview window the image is not displayed if i resize wider or longer than the image itself; i.e. if the vrtical or horizontal scrollbar disapears. I will investigate if it is c2j or abc.
Follow on.
If intially the preview window is larger than the image then i can resize how i wish without loosing the image.
If initally the preview window is not larger than the mage then if i resize wider i loose the image.
Follow up.
While testing I have noticed that when I have multipage report the SPIN control allows me to choose nuber of page higher than max page number.
I have implemented a workaround.
It seems to me that
SELF.PrtPrev:CurrentPage{PROP:RangeHigh}=RECORDS(SELF.ImageQueue)
fails; i.e. maybe c2j does not handle correctly prop:rangehigh
HIGH and LOW ranges are obeyed by spin control. I suspect that SPIN currently does not respond properly to dynamic changes to hi/lo range. Looking at code I suspect it will work if you key in the amount, it will check dynamic ranges.but if you click on up/down arrows I think these will only obey ranges set when control is initially created. Probably quick hack fix is in SpinControl. configureModel() should be called via adding tests for hi/lo range in isAWTChange() and handleAWTChange()
I have found the reason for loosing the image.
SELF.BorderFeq{PROP:Hide}=CHOOSE(THeight>WinHeight AND TWidth>WinWidth)
If I set this to
SELF.BorderFeq{PROP:Hide}=false
it is OK.
I think it has to do with different c2j and clarion control layering, as you are awere of.