BlockView_LoadDWG vs BlockView_DisplayBlock

Started by Fred Tomke, February 11, 2010, 11:42:49 PM

Previous topic - Next topic

Fred Tomke

Hello,

I've extracted a small function of mine for you to ask for a little help:

In the attachment you can find a project, a lisp, and two drawings.

  • open up the file drawing.dwg
  • load the lisp and make sure that the project is in one of your supportpaths
  • start command test_block
  • in the upper middle you can see a pull down, which increases at mouseover
  • select an other view
  • you cann see the "toolbar" keeps open after clicking
  • close the form
  • start command test_dwg and select the tree.dwg of the archive
  • you see the same tree
  • do as before and select an other view
  • suddenly it seems that the toolbar has closed, but it is certainly behind the blockview
  • when you have the same test with the toolbars at left or right they still keep open after clicking

I've also tried to make invisible and visible again, I also used ZOrder and so on. But I cannot keep the middle toolbar open after a new LoadDWG. Maybe there is another way I still don't to change the view without loading the file agein. Maybe you have an idea.

Thanks for watching.

P.S. Just before you begin: let's bet how many controls does this form contain?  :)

Fred
Fred Tomke
Dipl.-Ing. (FH) Landespflege

[ landscaper - landscape developer - digital landscape and urban design]

BazzaCAD

a.k.a.
Barry Ralphs
barryDOTralphsATgmailDOTcom

owenwengerd

I can't reproduce the problem here, but it sounds like the typical problem with overlapping sibling controls redrawing in a "random" order. I do notice that when the toolbar closes, the invalidated part of the blockview is redrawn with a focus rectangle, while the rest of the blockview is still drawn without one.  Also, when the dialog is small and the toolbars overlap, the middle toolbar covers the "open" arrow of the right toolbar.

That's a cool toolbar and I admire your creativity. I think in the end it will need to be implemented as a separate modeless form, but it will be interesting to see how far you can go with this approach.
Owen Wengerd (Outside The Box) / ManuSoft

andrew

wow Fred that is a cool toolbar
maybe when you have free time you can explain how you made that


velasquez

Hello Fred, 
Very good your work. 
Did you already think about isolating the control of BlockView? 
You can place controls of empty PicutreBox and with the same color around him. 
I know that that is a mending but it can work.

Velasquez

Fred Tomke

Quote from: andrew on February 12, 2010, 10:24:33 AM
maybe when you have free time you can explain how you made that

andrew, it's hard to explain. the most work I had to do is to paint and to draw all the single items of the toolbar by myself. In the end there are only 4 controls on this form: each complete toolbar is a picture, each button is assembled by a drawn edge (drawn by DrawEdge method) and a painted picture (using PaintPicture method). The most important thing you have to have in mind is the OnPaint method, which is called whenever the PictureBox has to be redrawn. In the event the function to paint the complete picture will be executed.

andrew, I invite you to have a look at the code and the project I've attached in my initial post. So you can follow what I've done.

Fred
Fred Tomke
Dipl.-Ing. (FH) Landespflege

[ landscaper - landscape developer - digital landscape and urban design]

Fred Tomke

Quote from: BazzaCAD on February 12, 2010, 12:13:02 AM
wow that's a really cool dropdown toolbar.

Thank you. Yes, and it would be still better if I could slow down the opening and closing a bit using dcl_delayedinvoke in this modal form   ;D . I don't want to use the AutoCAD command _delay as it was used here.

Fred
Fred Tomke
Dipl.-Ing. (FH) Landespflege

[ landscaper - landscape developer - digital landscape and urban design]

Fred Tomke

Quote from: velasquez on February 12, 2010, 12:39:26 PM
Did you already think about isolating the control of BlockView? 

Hi velasquez,

I'm not sure what you mean with this. Can you give me support to do this? Would it solve my problem mentioned on top?

Fred
Fred Tomke
Dipl.-Ing. (FH) Landespflege

[ landscaper - landscape developer - digital landscape and urban design]

Fred Tomke

Hi Owen, thank you for your reply.

Quote from: owenwengerd on February 12, 2010, 08:44:37 AM
I can't reproduce the problem here, but it sounds like the typical problem with overlapping sibling controls redrawing in a "random" order.

Yes, this will be the case. The thing, I really don't understand, is why the behaviour is different using LoadDWG to the case using DisplayBlock. That's why I'm looking for a way to change the view without loading the file anew.

Quote from: owenwengerd on February 12, 2010, 08:44:37 AM
Also, when the dialog is small and the toolbars overlap, the middle toolbar covers the "open" arrow of the right toolbar.

Yes, that's a bad interface design by me. I thought about a quick and easy solution. Normally, the sum of the widths of all picture boxes is the result of the whole form's width. But when it is too small there were only two ways: either I make two lines of buttons - but then my generic function to "open" the pulldown must be changed, and that I didn't want to do. Or I also increase the width of the toolbar when opening the toolbar. That's why the middle toolbar is the first one in the Z/TAB order  ;) . I think, it would be better to increase the toolbar's width equal to both sides...

Quote from: owenwengerd on February 12, 2010, 08:44:37 AM
I think in the end it will need to be implemented as a separate modeless form

I must honestly say, it will stay in a modal form. This funtion it is a part of our huge product to have a closer look to the block before inserting it... (see the video below). In this case I close the toolbar after changing the view to avoid the issue...  ;D

Fred
Fred Tomke
Dipl.-Ing. (FH) Landespflege

[ landscaper - landscape developer - digital landscape and urban design]

velasquez

Fred, 
I am working a lot in the delivery of a project, 
It will be very good to try to solve this problem. 
I will make some work as soon as possible. 
 
Regards.

Fred Tomke

Quote from: velasquez on February 12, 2010, 03:27:40 PM
I am working a lot in the delivery of a project, 

velasquez, it doesn't hurry. Take as much time as you need. I will keep the result now as it is. I'm also working hard on many building sites at the time. You can deduce it by the number of my questions I start to post in the forum  ;) .

Fred
Fred Tomke
Dipl.-Ing. (FH) Landespflege

[ landscaper - landscape developer - digital landscape and urban design]

owenwengerd

Quote from: Fred Tomke on February 12, 2010, 01:36:21 PM
I must honestly say, it will stay in a modal form.

I was referring only to the toolbars. I think you should try the approach of making them separate modeless forms that you show and hide as needed.
Owen Wengerd (Outside The Box) / ManuSoft

Fred Tomke

Quote from: owenwengerd on February 12, 2010, 06:52:10 PM
I was referring only to the toolbars. I think you should try the approach of making them separate modeless forms that you show and hide as needed.

Aaah, now I got you. Hm, I'm just thinking about it. I hope the toolbar forms won't be shown behind the parent form. I'm always frightend about it, because I often (not always, but often) reproduce this when I call a modal or a modeless form from a modeless form or a palette. Then the newly created form will be shown on top at first and then the focus seems try turning back to the parent from with the result that the new form is shown behind the parent (I hope I explained a bit understandable). But I have to try it at first...

Fred
Fred Tomke
Dipl.-Ing. (FH) Landespflege

[ landscaper - landscape developer - digital landscape and urban design]